Subject: Re: Question on data maping transformation

From: Zheng Gengbin <[email-masked]>
Date: Fri, 14 Mar 1997 09:22:37 +0800 (EAT)

On Thu, 13 Mar 1997, Guansong Zhang wrote:

> The data maping transformation (trans1) produce different results when it runs,
> here is an example when use it to scan forall3.f in testsuite:
> 
> % diff forall3.1.f forall3.1.f.bak
> 22,24c22,24
> < !HPF$      processors PROC2223(1:4)
> < !HPF$      template TMP9049(6:349)
> < !HPF$      distribute TMP9049  (block) onto  PROC2223
> ---
> > !HPF$      processors PROC1291(1:4)
> > !HPF$      template TMP797(6:349)
> > !HPF$      distribute TMP797  (block) onto  PROC1291
> 26c26
> < !HPF$      align X (DM9430) with TMP9049(1*DM9430+0)
> ---
> > !HPF$      align X (DM1634) with TMP797(1*DM1634+0)
> 
> this design is not good for bug detecting in the package. Can you change it?
> 

	The temp variable is genreated randomly according to the time , that's 
because although in trans1 , there still 8 passes in it . It seems i 
cannot use a counter to create a temp variable ,otherwise some variable 
with same name will occur in separate passes . And trans1 is designed so 
that user can specify certain kinds of pass type instead perform all the 8 
pass fully .So to prevent trans1 in creating same name is important . 
	But i think there still have some way to solve this problem ,I will
try this later .

> There are also other problems concerned with this pass, I will discuss them
> later.
> 
> By the way, two bugs merged in the latest version, causing trans0 can not
> handle forall1-4 corretly. I am working on them. Please don't make update for
> the moment.
> 

	The situation is old transG ( before my change , I have kept old
version for comparasion ) can handle forall1.f and forall2.f , but core
dump at forall3.f and forall4.f .
	Now in my place , I have fixed the problem and transG can pass
all these 4 samples.

	Anyway , I think the problem is that you must run tran1 before
trans0 , otherwise forall2.f sure will core dump when trans0 . That's
because in distarray.C , line 65 , you will find I commented your function
of getlinerexp ,and use the result produced by trans1 directly .That's
because getlinerexp is not well coded , and seems cause trouble sometime.
I think we need not let transG do all the work , use the result of tran1
if it can . So I think you needn't waste time on it . 

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Sat, 15 Mar 1997 09:26:11 +0800 (EAT)

On Fri, 14 Mar 1997, Guansong Zhang wrote:

> On Mar 14,  9:22am, Zheng Gengbin wrote:
> >
> Yes, I think you'd better use other method than this. So we can have a
> determinative output. This is quite important for us to keep the progress of
> the project not involved in bugs.
>

	I have changed my strategy of generating temp variable now . I will
give you a latest version as soon as possible.
 
> Another thing I like to mention, I think the optional 8 passes in trans1 is
> more useful to debug. When compiler is used by a user, he will use all the 8
> passes, right?
> 
> 

	Yea , it just provide a flexible way for programmer or user .

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Sat, 15 Mar 1997 11:39:36 +0800 (EAT)

> > 	Now in my place , I have fixed the problem and transG can pass

in forall4.f :
!HPF$ PROCESSORS P(4)
!HPF$ TEMPLATE T(-12:2170,-25:4171)
!HPF$ DISTRIBUTE T(*,CYCLIC) ONTO P
!HPF$ ALIGN X(i,j) WITH T(2*i-6, 4*j+7)
!HPF$ ALIGN Y(i,j) WITH T(2*i-8, 4*j+3)

	In the first dimension , T is collapsed . This will cause core
dump in :
Program received signal SIGFPE, Arithmetic exception.
0x805a09c in devide (s1=2183, s2=0) at detect_comm.C:134
134             int s = s1 / s2;

	because the dad_x->numProcs is zero .

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Mon, 17 Mar 1997 19:20:26 +0800 (EAT)

On Sat, 15 Mar 1997, Guansong Zhang wrote:

> On Mar 15, 11:39am, Zheng Gengbin wrote:
> > Subject: Re: Question on data maping transformation
> >-- End of excerpt from Zheng Gengbin
> 
> I think this is a portability problem, please let me know where it is. Because
> the forall4.f can be compiled here. You can do in 1.74
> 
> hpf2nf -2 -0 forall4.f
> 
> and a forall4.2.0.f is generated.
> 

Please check this carefully , in your new version , it still core dump .
The error message on HP is floating fault (divede by zero) .
I have to define another strategy to detect the communication ,so that
foall4.f can be passed .

Zheng