RFC: GIMPLE tuples. Design and implementation proposal

Rob1weld@aol.com Rob1weld@aol.com
Mon Jul 9 07:30:00 GMT 2007

>In a message dated 7/7/2007 4:04:01 A.M.  Pacific Daylight Time, Rob1weld 
>This page  http://deputy.cs.berkeley.edu/ has a link to this document  
>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 

And ignoring that portions of GCC are not written in "C": examples  being the 
use of configure scripts to spit out snippets of "C" to (test for  compiler 
features), use of flex, yacc, the various files generated and then  compiled.
GCC is not 'just "C"' - probably be more portable if it were  ...

An example of a project using ML for "Intermediate  Representation":

- The acronym CAML originally stood for Categorical Abstract Machine  
- It has a large standard library that makes it useful for many of the same  
applications as Python or Perl, as well as robust modular and  
programming constructs that make it applicable for  large-scale software 
- ML-derived languages are best known for their static type systems and  
type-inferring compilers. OCaml unifies functional, imperative, and  
object-oriented programming under an ML-like type system.
- OCaml's static type system eliminates a large class of programmer errors  
that may cause problems at runtime. However, it also forces the  programmer 
to conform to the constraints of the type system, which  can require careful 
thought and close attention. A type-inferring  compiler greatly reduces the 
need for manual type annotations.
- OCaml is perhaps most distinguished from other languages with origins in  
academia by its emphasis on performance. Firstly, its static type  system 
renders runtime type mismatches impossible, and thus obviates  the need for 
runtime type and safety checks that burden the  performance of dynamically 
typed languages, while still guaranteeing  runtime safety.
- Also the reason that you made mention of, CIL is written in that  language.
The object (and library) files are completely linkable with  "C" code.

- organizes C’s imperative features into expressions,  instructions and 
based on the presence and absence of  side-effects and control-flow. 
- Every statement can be annotated with successor and predecessor  
- CIL provides an integrated program representation that can be used with  
that require an AST (e.g. type-based analyses and  pretty-printers), as well 
as with 
routines that require a CFG (e.g.,  dataflow analyses). 
- CIL also supports even lower-level representations  (e.g.,  three-address 

- Deputy is implemented using the CIL infrastructure for C program analysis  
and transformation, and it uses GCC as a back end.
- Deputy is a C compiler that is capable of preventing common C programming  
errors, including out-of-bounds memory accesses as well as many other  common 
type-safety errors. It is designed to work on real-world code,  up to and 
including the Linux kernel itself.
- Deputy allows C programmers to provide simple type annotations that  
pointer bounds and other important program invariants.  Deputy verifies that 
your program adheres to these invariants through  a combination of 
and run-time checking.
- Unlike other tools for checking C code, Deputy provides a flexible  
language that allows you to describe many common  programming idioms without 
changing your data structures. As a  result, using Deputy requires less 
effort than other  tools. In fact, code compiled with Deputy can be linked 
directly with  code compiled by other C compilers, so you can choose exactly 
when  and where to use Deputy within your C project.

I think you will find that Deputy is like "C" with a few extra comment  lines.

Of course you do not have to have the advantages of using Deputy. You  can 
read about CIL and implement a few of CIL's ideas in "C" and use  those in 
Deputy with CIL provides both a higher level and a lower level than the  
implementation and would provide a "C" compiler that has more checks  as 
opposed to 
one that always has a few bugs (upon which all the rest of the  toolchain is 
Portions of the "C" testsuite that fail are a few years old.

You mention "Better memory savings? Faster processing?". If that is all  you 
then what language do you think we would be using - hint it is not  very 

I respect the fact that people at Redhat are competent programmers, I do  not 
know why 
you are dismissive of Berkeley, (or Rice, NYU, TAMU, or any of a number of  
places with 
ideas to contribute to your project). I was trying to keep my suggestion  
closely aligned 
to your goal rather than to give you a "do it this way - it is better"  
argument and suggest 
you follow a different course of action.
Have you tried to compile GCC 4.3 with CIL ? I have. You are not required  to 
simply have a look at what others are doing and incorporate the best ideas  
into your
efforts. Your "tuple paper" seemed to end abruptly and was not fleshed  out.


More information about the Gcc mailing list