Thomas Lavergne <[EMAIL PROTECTED]> wrote: > *) is GIMPLE truely front-end independent (no nore specific hacks)?
Yes, mostly. There are some so-called "lang-hooks" to ask some additional information to the frontend, but it's mainly about the type system (eg: there is a langhook to ask the frontend if two types are equivalent). > *) are all tree SSA optimizations run on individual function's GIMPLE > trees or do some start at GENERIC level? Most passes work with GIMPLE (either hi-gimple or low-gimple) in SSA form, but others work without SSA form or even on GENERIC (for instance, tree-nested.c can be called an optimization pass -unnests the nested functions - and it works in GENERIC form). Some loop optimizations work in the so-called loop-closed SSA form. Anyway, you can say that *most* passes work in GIMPLE form. > *) are all front-end designed to pass GENERIC to the middle-end (which > then gimplify) or do some directly provide GIMPLE trees? C and C++ fully use trees as internal representation of the frontend data. Basically, they build and work with GENERIC trees enriched with other frontend-specific trees. They then gimplify these trees, using frontend-specific gimplification callbacks that know how to gimplify the frontend-specific trees. Other frontends like Fortran and Ada work with totally different data structures and build GENERIC trees as a last conversoin step just to feed the middle-end (which are then passed to the gimplifier). > *) are the various function's GIMPLE tree the only structure that the > middle-end needs to write back-end code or are there other data that > should be created/obtained from the front-end? Not sure I understand the question. It looks like you could answer this yourself by opening one of the easiest optimization passes (see tree-*.c) and looking how it works. > *) is there a tool to browse the gimpled tree of your functions (before > and after some optimizations)? Not sure what you mean by "browse". You can use -fdump-tree-all to dump the trees after each and every optimization step, so you can see what each pass did. > I rapidly saw an option to dump the generic/gimpled tree to a C form. > (-fdump-generic-tree). Do you think it is theoretically possible to > design "inverse front-end" which would translate the gimple tree to a > selected language (transforming C++ code to C, C99 to C89, fortran95 to > C,...)? An other way of putting this, is: did we loose information or > can a smart tool recover from gimplifying? Are some open source projects > already looking at these aspects? I believe you could write a special backend which generates C code from the final GIMPLE form, so after all optimizations happened. You can't do that from the tree dumps though, as they don't carry enough information. > I am sorry, these are a lot of questions. You can point me to any > forum/mailing list archive or document: I can learn by myself. Are gcc's > internal documentation available somewhere (without installing the gcc > grom source)? The source code contains the source TeX files for the internals documentation. "make doc" should build the dvi version even without compiling the compiler itself. -- Giovanni Bajo
