Hi there i have went through some of the GIMPLE stuff (mostly went through the GCCSummit 2003 paper). I think i have some reservations on the structure and semantics of GIMPLE. Most of my compiler experience comes from interactions with the SUIF2/MachSUIF2 infrastructure ; admittedly Machine-SUIF is unstable, has a small user base and it's DEAD, however its IR (named SUIFvm or SUIF virtual machine) is more true three-address-code than GIMPLE.
In my view, GIMPLE IR should be comprehensible as (almost) ready-to-run VM code, by an interpreter or by a target VM. Due to its nature, GIMPLE is not that far from the machine-level. E.g. it is possible to derive general metrics for application source files and perform some analyses as for example: - (early) execution profiling (altough tree-ssa already supports profiling) - dependence graph generation (DDG) at the GIMPLE IR level The following points discuss GIMPLE issues regarding (alternative) further simplifications and interpreting GIMPLE as a VM. I understand that the further simplifications might possibly hamper tree-ssa optimizations thus i'm focusing more on viewing GIMPLE as a VM. 1. First of all, i would like to ask: i've seen that a new branch, gimple-tuples-branch has been started. Please, correct me if i'm wrong but the purpose of gimple-tuples is to provide a new facet (and API additions) of the GIMPLE IR (a linear one). Does gimple-tuples bring anything new to the IR? I don't mean "real" changes to the IR, just complementary ways of doing things. Relative stuff to this follow and maybe gimple-tuples-branch already answers some of these. 2. GIMPLE IR does not seem so clean cut to me. a. Conditional jumps in GIMPLE are not true three-address-code since they specify two (2) branch targets (in their general form). E.g.: if (cond) then goto target1; else goto target2; IMHO, this should be split (or at least made splittable) into: if (cond) then goto target1; if (!cond) then goto target2; It seems redundant but it's really clean. b. Are LOOP_EXPRs decomposable to combinations of if-then-else and gotos? It would help for VM (virtual machine) execution of GIMPLE IR. Ideally, a GIMPLE representation of a program should be possible without use of LOOP_EXPRs. c. It would be interesting to support simple if-then statements in GIMPLE. I.e. that do not contain blocks of statements with size larger than one. d. Demoting of function arguments into virtual registers. This would further clean up GIMPLE in the sense of solely using virtual registers and memory locations (accessed via virtual register pointers). A translation to SSA form and back (GIMPLE->SSA->GIMPLE) would solve that (i used to do a cfg->ssa->cfg in MachSUIF for the same reason); maybe that's already possible with tree-ssa. 3. The "dirty" way to do things would be to post-process the GIMPLE dump but in the long term i would to have such things added in the GCC infrastructure (eventually I would try to add these locally, but this shall take a really long time as i don't really know anything regarding the GCC frontend and middle-end yet). 4. What is the current state of the gimple-tuples branch? 5. I'm aware of the LLVM project and the significant amount of things being supported there. GIMPLE VM could be a quick (and dirty) way of having VM code from all major frontend languages supported in GCC. LLVM representation is a bit high-level to me and things (as those discussed above) would have to be done at each target architecture. Kind regards Nikolaos Kavvadias PS: I'll checkout (and try) the gimple-tuples-branch at its current state around Monday.
