Re: RFC: GIMPLE tuples. Design and implementation proposal

[Rob1weld at aol dot com]

>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time,  
dberlin@dberlin.org writes:
>On 7/9/07, Rob1weld@aol.com  <Rob1weld@aol.com> wrote:
>> >In a message dated 7/7/2007  4:04:01 A.M.  Pacific Daylight Time, Rob1weld
>>  writes:
>> >This page  http://deputy.cs.berkeley.edu/ has a  link to this document
>> http://hal.cs.berkeley.edu/cil/
>>  >which describes a means to obtain  three-address code here
>>  http://hal.cs.berkeley.edu/cil/ext.html#toc24 .
>>
>>  >>2007/7/08, Diego Novillo <_dnovillo@redhat.com_
>>  (mailto:dnovillo@redhat.com) >:
>> >>Any  specific  reasons why we should?  Better memory savings?  Faster
>>  >>processing?  It's not clear from your message what the   advantages 
would
>> >>be (ignoring the fact that their  implementation  language is completely
>>  >>different).
>>

>You haven't explained what advantages CIL's IR has over  GIMPLE.
I thought it was well explained on page: 
_http://hal.cs.berkeley.edu/cil/cil001.html_ (http://hal.cs.berkeley.edu/cil/cil001.html)  
 
Please look at this page:
_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ 
(http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) 


If you choose to run CIL _locally_ (not add it to GCC, but _only_ run it on  
your computer) 
then you can program in "Deputy". The Deputy language is very much like "C"  
but uses 
a few additional annotations which allow program checking when it is  
compiled. 
 
Deputy converts it's "C" to 'regular-C' which is processed by GCC. The  
result is (obviously) 
executable. A simple SED script can remove the annotations and leave  you 
with 'regular-C' 
which can then be released as part of GCC (or you can release 'Deputy-C'  
with GCC and 
include the SED script which would process the file and produce the source  
for stage 1.
 
Doing that "buys you" a better quality of code tested by CIL (and GCC)  which 
is more likely 
to be correct since it is checked twice. It "costs you" having to learn a  
few Deputy annotations.
 
When you have the CIL source to look at you can read the source  and see if 
it helps you
with GIMPLE that you are re-writing. You don't need to include CIL with GCC  
4.3 (but you 
could since you don't need to learn Ocaml to compile it).
 
The result will be better coding that looks no different and compiles  
without any modification 
to the current way of building GCC. The second link (above) may help you  
more.


> I can't tell, but you may be under the impression GIMPLE is  something
> in the future. It is not.
> Our IR is already GIMPLE,  and a three address code simplified form of
> C. We are simply talking  about changing the underlying datastructures
> that store it.

Yes, I know GCC uses GIMPLE.
 

>Hint: CIL's IR is almost exactly GIMPLE with alpha renaming over  multiple 
units.
>--Dan
 
It is your project to write the way you want. You "RFC letter" said  
"Thoughts/comments on the 
proposal?". My reply is that this 
page:_http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_ 
(http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html) 
and this site: _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html_ 
(http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html)  provide  a
better explanation of IR issues. You might also wish to read 
_http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/)  or
this one _http://www.cminusminus.org/_ (http://www.cminusminus.org/)  or 
_http://www.nabble.com/Gnu---Lightning-f1717.html_ 
(http://www.nabble.com/Gnu---Lightning-f1717.html)  or
... 
 
Best of luck with your project, I hope it brings a _huge_ advance to  GCC.
Rob