Subject: Re: 1.75

From: Zheng Gengbin <[email-masked]>
Date: Thu, 27 Mar 1997 19:34:11 +0800 (EAT)

On Wed, 26 Mar 1997, Guansong Zhang wrote:

> On Mar 27, 11:09am, Zheng Gengbin wrote:
> > Subject: Re: 1.75
> >
> >
> > 	I cannot believe your current version can work on the testsuite
> > samples correctly , there are some obvious errors there
> 
> The *.rec file is used only as a reference, they are not corret. But the closet
> thing to the correct program I can get.
>

	I don't know if the 4 forall?.f can be parsed in your place , are
they core dump ? 
	Also , I don't think there have any portablilty problem , because
I have tried the same version on HP ,RS6000 and Linux with same result .the
problem is we have bugs in program . I have tried to fix them and it seems
no so good .
 
> >
> > forall4.f:
> >
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x8054983 in devide (s1=215, s2=0) at detect_comm.C:135
> > 135             int q = s1 % s2;
> > (gdb) bt
> > #0  0x8054983 in devide (s1=215, s2=0) at detect_comm.C:135
> > #1  0x80546fd in pcrc_detect_communication (dad_x=0xbffff274,
> >     dad_y=0xbffff25c, l=0xbffff258, u=0xbffff254, stride=0xbffff250,
> >     a0=0xbffff24c, b0=0xbffff248, a1=0xbffff244, b1=0xbffff240,
> >     amount=0xbffff23c) at detect_comm.C:31
> > #2  0x804b9dc in detect_communication (s=0x80b8d80, counter=1)
> >     at reference.C:286
> > #3  0x804bc5b in detect_forall_reference (s=0x80b8d80) at reference.C:412
> > #4  0x8049c05 in analyse (s=0x80b8d80) at hf.C:743
> > #5  0x8049919 in analyse (s=0x80b8e38) at hf.C:593
> > #6  0x80498a9 in analyse (s=0x80b8e48) at hf.C:572
> > #7  0x804a3af in main (argc=2, argv=0xbffff360) at hf.C:1086
> > #8  0x8048c7b in _start ()
> >
> 
> I think in 1.75 you know where the problem is, right? Please let me know this
> portability problem first. Let's first have a portable 1.74 without the
> improvement.
>

	This is not a portablilty problem , I think .
!HPF$ DISTRIBUTE T1(*,*,BLOCK) ONTO P
!HPF$ DISTRIBUTE T2(*,*,BLOCK) ONTO P
!HPF$ ALIGN X1(i0,i1,i2) WITH T1(2*i0+5,2*i1+0,3*i2+1)
!HPF$ ALIGN X2(i0,i1,i2) WITH T2(2*i0+3,1*i1+2,3*i2+7)

	because the template T1 and T2 is collapsed on processor P ,
so when creating DAD in fill_DIM , the left dad have number of processor
of 0 , which cause the Arithmetic exception in detect_comm.C . 
I tried to fix this bug in detect_communtion() , I compare the left dad's
processor number , if it equals to 0 , I will assume there is no 
communication.
This is the code I added :
  if (numProcs == 0) {
        printf("Number of Procs is zero ,assume no communication.\n");
        return 0;
  }
 
> >
> > Also diff the result of the forall3.f and forall4.f between the version
> > of mine 1.75 and your record , I think the difference just reflect the bugs
> > in old version :
> >
> > >diff forall3_node.f forall3_node.f.rec | more
> >
> > 13,14c13,14
> > <       real :: Y(0:2292149)
> > <       real :: X(0:2292149)
> > ---
> > >       real :: Y(0:9162050)
> > >       real :: X(0:9162050)
> > 26,27c26
> > <       call pcrc_set_array_align (pcrc_dad_Y,1,0,1088,2,(-8),pcrc_rng_T(1&
> > <      &))
> > ---
> > >       call pcrc_set_array_align (pcrc_dad_Y,1,0,1088,2,8,pcrc_rng_T(1))
> > 32,33c31
> > <       call pcrc_set_array_align (pcrc_dad_X,1,0,1088,2,(-6),pcrc_rng_T(1&
> > <      &))
> > ---
> > >       call pcrc_set_array_align (pcrc_dad_X,1,0,1088,2,6,pcrc_rng_T(1))
> > 210c208
> > <       call pcrc_set_array_align (pcrc_dad_Y,1,5,348,1,0,pcrc_rng_T(1))
> > ---
> > >       call pcrc_set_array_align (pcrc_dad_Y,1,5,348,0,0,pcrc_rng_T(1))
> >
> >
> > Line 26,27c26 , the offset is -8 not 8 ,
> > Line 32,33c31 , same as above.
> 
> This is because the rec file is not passed by trans1 in 1.74, which cause more
> problem.
> 
> > Line 210c208  , the stride should be 1 not 0 ,
> > please check the source file and make your decision .
> 
> This is a bug I don't have time to check yet. Please let me know where the
> problem is if you have fixed it.
> 

	I cannot rememer if I erver touched this bug .

> By the way, I don't think the size of Y and X in your version is correct,
> please check it.
> 

> > 13,14c13,14
> > <       real :: Y(0:2292149)
> > <       real :: X(0:2292149)
> > ---
> > >       real :: Y(0:9162050)
> > >       real :: X(0:9162050)

Please check it , the source code of forall3.f is
      REAL X(0:1088,-2:1041), Y(0:1088,-2:1041)
!HPF$ PROCESSORS P(4)
!HPF$ TEMPLATE T(-12:2170,-25:4171)
!HPF$ DISTRIBUTE T(*,CYCLIC) ONTO P

So the Template T 's size is  (2183,4197) ,
The array size is  2183*(4197/4) = 2292150 . ( notice that the distribute
format of first dimension of T is NOP , the second is CYCLIC to P ,whose
size is 4.

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Thu, 27 Mar 1997 19:57:13 +0800 (EAT)

The diff result of forall4_node.f forall4_node.f.rec is :
diff forall4_node.f  forall4_node.f.rec
14c14
<       integer :: X6(0:3604607)
---
>       integer :: X6(0:7144847)
16,20c16,20
<       integer :: X4(0:1796024)
<       integer :: X3(0:5923007)
<       integer :: X2(0:2782723)
<       integer :: X1(0:7359449)
<       integer :: X0(0:1224287)
---
>       integer :: X4(0:3592049)
>       integer :: X3(0:11846015)
>       integer :: X2(0:5546771)
>       integer :: X1(0:14718899)
>       integer :: X0(0:2448575)

	So your size is just twice as many as the size of my version ,
Again ,I think you forget to divide the processor size of P whose size is
2.

	To summerize the last 2 letters , I don't think my version have
a lot of bugs in it . And I don't know how you got your record node files
of forall3_node.f.rec and forall4_node.f.rec ,I am sure your machine will
core dump on these two files , this is not a portablilty problem , 
please check it carefully.

Zheng