Re: RFC: GIMPLE tuples. Design and implementation proposal
>2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >Following up on the recent discussion about GIMPLE tuples >(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_ (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ), we have summarized >our main ideas and implementation proposal in the attached document. > >This should be enough to get the implementation going, but there will be >many details that still need to be addressed. > >Thoughts/comments on the proposal? > >Thanks. I read your document _http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf_ (http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf) with great interest. This page _http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/) has a link to this document _http://hal.cs.berkeley.edu/cil/_ (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_ (http://hal.cs.berkeley.edu/cil/ext.html#toc24) . If you ask nicely they would let you use CIL's code in GCC ;) . Rob
Re: RFC: GIMPLE tuples. Design and implementation proposal
>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 <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >>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). 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": _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html) Ocaml: - The acronym CAML originally stood for Categorical Abstract Machine Language. - 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 object-oriented programming constructs that make it applicable for large-scale software engineering. - 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. CIL: - organizes C’s imperative features into expressions, instructions and statements based on the presence and absence of side-effects and control-flow. - Every statement can be annotated with successor and predecessor information. - CIL provides an integrated program representation that can be used with routines 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 code). Deputy: - 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 describe pointer bounds and other important program invariants. Deputy verifies that your program adheres to these invariants through a combination of compile-time and run-time checking. - Unlike other tools for checking C code, Deputy provides a flexible annotation language that allows you to describe many common programming idioms without changing your data structures. As a result, using Deputy requires less programmer 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 simply read about CIL and implement a few of CIL's ideas in "C" and use those in GCC. Deputy with CIL provides both a higher level and a lower level than the current 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 built). Portions of the "C" testsuite that fail are a few years old. You mention "Bette
Re: RFC: GIMPLE tuples. Design and implementation proposal
>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time, [EMAIL PROTECTED] writes: >On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >> (mailto:[EMAIL PROTECTED]) >: >> >>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
Re: RFC: GIMPLE tuples. Design and implementation proposal
>On 7/10/07, [EMAIL PROTECTED] writes: >>On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >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) >No, since as i said, their IR is the same as GIMPLE. You may say that but I am not the only one who says that CIL is both higher level and lower level than what we are using. IE: the _lower_ level portion is _simpler_ than GIMPLE - which _is_ what you want, is it not ? Maybe this page will make you feel more at home: http://www.gnu.org/software/gcc/projects/cli.html While this is a different implementation of CIL than what I suggested (since I also suggest Deputy, which needs the _other_ CIL, though perhaps it could work with this one), this one being the "Common Intermediate Language", the one I suggested is the "C Intermediate Language" it also discusses GIMPLE: CIL simplification pass Though most GIMPLE tree codes closely match what is representable in CIL, _some_ _simply_ _do_ _not_. ... Such a constrained GIMPLE format is referred as "CIL simplified" GIMPLE throughout this documentation. As I mentioned, it is your project to do your own way. I just would not want to see you spend a lot of time coding to duplicate prior work. You say you have already seen what I have suggested and want to start from scratch. OK. Rob
