GIMPLE issues and status of gimple-tuples

[nkavv at physics dot auth dot gr]

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.