🚀 go-pugleaf

Hi folks,

 
	I'll explain the context before asking the question:

	We are currently taking over a compiler (a research 
	project from McGill university) that will perform 
        compilation  (for a number of platforms,
	e.g. RS/6000, T800, i860, etc...).  The idea is to  
	exploit fine-grain parallelism; so the compiler design is driven
	by analyses (general alias and dependency analysis) and 
        transformations that ultimately generate  programs.  
	The compiler is divided into 3 phases:  FIRST, SIMPLE and LAST.
	It is heavily based on GCC, and therefore will be free software.

	FIRST:  This is really just the parser phase.  This phase was
	taken from gcc.

	SIMPLE: This phase is where dependency analysis, alias analysis,
        and software pipelining etc.
	are performed.  It is basically a 3-address form of FIRST.  We
	created our own AST, which is a simplification of the original AST.
	The SIMPLE grammar is powerful enough to incorporate almost all C
	language constructs, yet simple enough so that optimization and
	analyses rules can be applied.  It is hardware-independent.

	SIMPLE was created to simplify the dependency analysis, alias 
	analysis, and software pipelining phases.  Of particular interest 
	is the pointer analysis portion of the compiler.  The strength of
	the McGill compiler is based on the fact that analyses can be 
	performed on general structures, and not just on arrays and variables.
	This is particularly useful when one wants to compile on a 
	super-computer.

	So, we definitely want to keep this portion of the compiler.
	The phase that interests us now is compiling on all platforms
	that gcc compiles on.   
 
	LAST:  This phase takes care of instruction scheduling and register
	allocation, and code generation.  It is really a binary tree, from
	which BURG is used to walk the tree and spit out code.  In order to
	do this, we have to write up machine description files.  They are
	much less complicated than the ones provided in gcc, but nonetheless
	a lot of work is required to fully test these .md files.  

	*** This phase is very similar to RTL.  i.e.  We have PLUS, MINUS,
	MULTIPLY, ... LT, GT, EQ, ..., LSHIFT, LROTATE, ..., AND, ...,
	almost in a one-to-one correspondence.   ***

	I hope the context is clear enough.  The idea now is to somehow
	reconcile our compiler (which currently compiles only on a 
	theoretical machine DLX) with gcc at the LAST level, in order to 
	make code generation for all the target architectures more efficient.  
	We would like to take advantage of the fact that gcc is a respected, 
	popular compiler that generates code for most of the architectures we
	will ever require.  

	Our idea was to go from LAST to gcc gen-rtl, suppress gcc pseudo 
	registers (if possible), skip the gcc optimizations and register 
	allocation, and go straight to gen_assembly to generate the code.
	What's your feeling on this?
	In order to do this, we have to convert our LAST binary tree
	representation of the user program to RTL format.  The question is 
	where is the entry point of RTL generation?  We would like to
	take advantage of the machine-specific optimizations done after 
	RTL is generated from AST.  
	So, which entry point do you suggest?
	** The idea is not to re-write gen_rtx, but to simply invoke it to 
	   TRANSLATE out LAST program to RTL format.  **
	Do you think using this approach is feasible?  
	If so, in your experience, how long does it usually take an 
	above-average Masters student to understand the RTL generation phase?
	Do you have any comments that may help us?  
	Any warnings or problems you may see in our approach?
        Any good source of documentation on RTL? 

	In any case, I would like it if you answered as many of these
	questions as possible:
	1)  Can pseudo register allocation be suppressed?
	2)  When last.c reads the RTL to generate assembly, does it make
	    use of any flags/bits that might be set by phases other than 
	    the gen-rtl phase?


Thank you in advance for your time.
Vince Delle Donne
Research agent
Computer Research Institute of Montreal
(514)398-5475