Subject: Re: compiler construction library

From: Zheng Gengbin <[email-masked]>
Date: Wed, 27 Nov 1996 14:32:39 +0800 (EAT)

On Tue, 26 Nov 1996, Guansong Zhang wrote:

> >
> > 	Someone in our group is about to do a test on this xsageop , with the
> > experience when I wrote the transBD with Du and Yan , I think xsageop have
> > no serious problem itself ,the only thing we should do is to have a
> > global test or improve it gradually by using it.
> >
> 
> Yeah, that is one way.
> 
> >
> > 	I'd like to know your idea . In fact I feel there are not enough
> > method in some of the classes , I am thinking about add more methods to some
> > of classes in lib.
> >
> 
> I also agree with you on this.
> 
> >-- End of excerpt from Zheng Gengbin
>

	I have discussed this topic with my co-worker Lan Sai, According to
Pro.Xu's idea , he will join me and be the man who is in charge of this sage 
lib . He is a beginner of our project and he need more time to become 
familiare with our work.

> In the following, I am going to write my vision of the development of our
> project, and what position is this xsage lib in.
> 
> We are going to develop a practical HPF compiler which will compile real hpf
> program on distributed memory machine with MPI support. So you can think that
> the project devided into three parts:
> 
> 1). A run time lib, which have some machenisim like DAD will support different
> kind of communication needed by the application. At present time, we already
> have Adlib, which is good for regular communications. Later the irregular part
> may be added.
> 
> 2). A compiler construction library, which offers different kind of operations
> to compiler writer. We will discuss what those operations are later.
> 
> 3). An HPF compiler, it is developed just based on 2), and the code generated
> by it will use 1).
> 
> If we look at the above three parts in a higher level, we will find that, in
> fact, 1) and 2) are independent. and both of them have influence on 3).
> Different kind of 1) will results different kind of 3). And the better 2) is,
> the easier 3) will be constructed.
> 
> And one step further. From the point of 2). It doesn't matter what kind runtime
> lib is, what kind of compiler it support. If it provides a good interface for
> user to operate on IR, it can be used for any kind of compiler construction.
> 
> This is our ideal tools for compiler writing, from this point of view, it is
> more significant than compiler itself. The HPF compiler we constructed is only
> one particular use of this lib.
> 

	Yes , I agree with you above . This is very important if we want to
establish a good compiler infrastructure . 

	But I can see there is a little difference in our goal of our two side. 
Our nearest goal is to work out a qulified HPF compiler which can run on DAWN 
1000 , while your goal now is to construct a good compiler infrstructure . 
Anyway to improve our sage lib is as significant as to you and me . And we can 
both benefit from this .

> Now, let see what kind of things are needed in this lib.
> 
> At least three parts in my mind when I talking about this lib:
> 
> 1) constructing.
> 2) analysing.
> 3) restructuring.
> 
> The first one is use to build up those IR structures. The second part is do
> typical program analying, like flow analyse and data analyse. The third parts
> may include the simple things like insert a statement to complicated things
> like rearrage a loop.
> 
> We don't have all of them yet, but we need them for a good HPF compiler. By
> good, I mean it really can make some speed up for a lot of real applications.
> 
> Now we can come to xsage, what is its position in our project.
> 
> To me, sage++ lib is a user interface of the compiler construction lib. Because
> it prevides a clear concept of the IR, namely, different kinds of C++ classes.
> 
> But as you noticed, all those class's member functions were pourly organized
> and not completed. If we keep the above three kind of operation in mind, we can
> say:
> 
> the first one is implemented by those constructors, (Only a few of them, like
> HPF directive statement are not yet.)
> 
> the second one is partially implemented by those maping functions, such as
> SgStatement * SgStatement::childList1(int);
> 
> the third one is also partially implementd by functions like:
> void SgStatement::insertStmtBefore(... ...);
> 
> It is not an easy task to finish all those functions needed by an optimizing
> compiler. Different people will work on it. For example, I know an analyse lib
> is being developed by HIT.
> 
> But we need to make xsage as clear as possible, so that once those additional
> functions are built up, not only member functions can be added as an interface
> in the lib easily, but also it can be used by the compiler writer easily.
> (Those compiler writer doesn't need to be you and me, they may be someone only
> know a little about different kinds of definitions like IR, but as long as they
> get the concept provided by the interface, they can write their code
> comfortablly.)
> 
> I think we need two steps to achieve this:
> 
> 1) make xsage header file clear.
> 
> At present time, they are just put together to make things work. The old rule
> in our project doesn't apply. So things like VPATH are not supported yet for
> xsageop.
> 

	VPATH is a problem ? it seems to me that the only thing we should 
do is to define a VPATH in Makefile.in .

	I agree with you that we need to reorgnize the lib's header files.
But the question rise , how can we split the fromsage++.h the main header 
file apart while let the defintions still clear . I remembered we once 
discussed on whether split the header file by base-derived class  or by 
class types ( BFND ,LLND...).

> 2) classify those member functions.
> 
> Member functions in xsage need more organization. The more clear they are, the
> easier the compiler writer will feel. If we develope lots of member functions
> but no one else can use, that will be a total waste.
> 

	This issue I think is also concerned with a more detailed document.
And I also feel we have added some redundent classes definitions like 
TripletExp , which make the class structure worse .

> Ok, so much for the general ideas. What do you think about them?
> 
> We can discuss futher to detail those plans.
> 

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Thu, 28 Nov 1996 10:15:14 +0800 (EAT)

On Wed, 27 Nov 1996, Guansong Zhang wrote:

> First, let me once again emphasize that, a good enough compiler organization
> interface library is the base of our HPF compiler. With it, we can divide the
> project into three almost independent part:
> 
> 1) run-time builder
> 2) program analyse and restructure
> 3) compiler construction
> 
> It is the fundation of our cooperation work.
> 
> Don't consider xsageop as the compiler infrastructure, it is only the interface
> of the infrastructure. Make this interface clear is utmost important for both
> compiler development and infrastructure development.
> 
> In my last letter, I talked about two things, header file and member functions.
> We leave the second item for the future right now. Here let me say more about
> those header files.
> 
> In our hpfFrontEnd project, header files are organized (basically) in this way:
> 
> 1. They are devided as global header file, and local header file:
> 
> The global header file are those important data structures, which are:
> 
> a). needed by more than one modules located in different subdir, and
> 
> b). they should be something we can clear explain the meaning of them.
> 
> These global files are located in include dir. The frontend user supposed to
> include those global files to code their own work, namely, their compiler.
> 
> While the private header files are located in each subdir to serve their own
> module.
> 
> 2. The private header files are managed by each module developer, I don't
> emphasize their structure much. But the global header files are considered to
> be responsible by system integration, so it was designed in the way that no
> files has its own include file. By this, we can fingure out a clear dependence
> relations in makefiles and not need to put complicated conditional compiling
> directives like #ifdef. But this needs user to include all those files one by
> one. I call this feature as developer orianted header files, they are simple
> for the developer not for the user.
> 
> Now let's have a look at xsageop header files. Compared with the above, they
> are obviously a mess.
> 
> We can not pointed out which one should be move to include dir easily. And
> sage++user.h is a user orianted header file: the user can include this file
> only and do not need to care about others, at the cost of that they no longer
> know the file dependence.
> 
> So I think the first step to do something about the header files should be to
> make clear what should be considered as global one. And then decide wheather we
> also want to use user orianted header file style. (My thought is that since we
> are mainly developer ourself, support that may be not a good idea, it will
> complicated our work. But on the other hand we are also the user of the
> package. I don't know your feeling about it?)
> 
> Now what do you think about the plane? I am not sure if you have time to work
> on this. Please make comments.
> 

	Yes , I also feel the header file is totally a mess in xsageop .
there are 22 header files there :

baseClasses.h           macro.h                 sageroot.h
compatible.h            sage++callgraph.h       sets.h
db.h                    sage++classhierarchy.h  typedef.h
defs.h                  sage++extern.h          version.h
ext_lib.h               sage++proto.h           vparse.h
extcxx_low.h            sage++user.h            vpc.h
f90.h                   sage.h
fromsage++.h            sagearch.h

	Among these files , some are the same (almost) as the header files
in include (like defs.h ,f90.h ,typedef.h) , some can be removed ,like 
(sagearch.h , compatible.h,sageroot.h ,version.h ) , some seem can be merged
with some header files in unparse , like vparse.h . 
	I will first deal with the first issue of above . You can think about
the third .

	as to the sage++user.h , I think as a user orianted header file , it
is convienent to user , otherwise the usr have to include them one by one .
We can think it as an alternative , pepole can use it , but not must to.

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Thu, 28 Nov 1996 10:28:33 +0800 (EAT)

On Wed, 27 Nov 1996, Guansong Zhang wrote:

> On Nov 27,  2:32pm, Zheng Gengbin wrote:
> > Subject: Re: compiler construction library
> You mean you won't work on the lib mainly? Any way I want to know what's your
> next step, I am quite glad to co-work with you, indeed.
>

	Our next step is to further improved the transformation of forall ,
adding our strategy , and I cannot exclude the possibility of rewritting 
the transG , that's not because your transG is not ideal , we feel if we 
donot write transG ourselves , our lack of the experience in it will 
block our next work , such as the profiling and visualization of the 
running of the node program.

> No, you are wrong. Believe me, I think the nearest goal is something can run
> just the same way as you do.
> 
> But I am sure you know how much work is waiting ahead of us. With out a solid
> base, you can not acheive that goal. In fact the infrastructure has no use at
> all if it is not used for a real compiler. The compiler work can not be
> finished just by you and me. We need more people to know how to use the lib, so
> the work can be parted as different phase.
> 
> To do that, the first thing is that the lib is good enough for not only you and
> me to use comfortablly.
> 
> That is the way we can finally build up a qualified HPF compiler. Other wise we
> can only end up with some demo program. Don't you think so?
> 

	That's only my private thinking . If all as you said  , I am very glad 
to incorporate with you . The only problem is in these days , I have got 
some eye problem ,I am afraid I will got short-eyesight , so I limited my work 
time in front end of computer .

> I will discuss detail things with you in the next letter.
> 

Zheng