GIMPLE issues and status of gimple-tuples

[Nikolaos Kavvadias]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 

>>> Loops are always lowered to if-then-else and gotos.
>
> It has been true since low-gimple came about which came about
> before 4.0.0 was released. low-gimple means Ifs are also converted
> to "a?goto b;:goto c;"
>
> -- Pinski
>

Hi Andrew and fellow GCCers

I still believe that the following is better: Because i have seen work
very smoothly with CFG and CFG/SSA in Machine-SUIF.
if (a) goto b;
if (!a) goto c;

it is more natural for the gimple-tuples case.

I'm looking for what's already there for data-dependence graph
extraction at the GIMPLE level. It seems that at a time there was a
source couple:
tree-dg.c
tree-dg.h
where data-dependence data structure primitives (i.e. graphs) and API
elements (for manipulation) were defined. This was happening around
2004 for the lno-branch.

Now, the lno-branch seems unchanged for the last 2 years (merged into
mainline?) but the tree-dg files are not there.

Have they been eliminated? Has the DDG support been reused somewhere
in the gcc sources? Would it be helpful to revive "tree-dg"?

And about gimple-tuples:
Do gimple-tuples support  DDG extraction on tuples GIMPLE IR? If it's
not there, is anyone interested in developing this (i mean together
but i'm just starting with GCC so please be gentle).

Also: gimple-tuples focuses more on low-GIMPLE right? I mean the
if-then statements (cond_expr) that incorporate compound (in the sense
of not being simple assignments or gotos) statements (with possibly
more than one statements) are meaningful in tree-oriented GIMPLE but
not so natural for tuples-oriented GIMPLE.

The following is part of the GIMPLE grammar (current gccint document)
and provides the syntax of an if-stmt:

if-stmt : COND_EXPR
op0 -> condition
op1 -> compound-stmt
op2 -> compound-stmt

I'm interested in developing a transformation for decomposing for
eliminating the use of compound-stmts in GIMPLE IR (it should be
optional). This would a little more structured code so it is a road
that probably makes a compromise for some optimizations (or not).
After the transformation it would be easy to extract DDG to which real
"assembly-like" dependencies would map to. Further, I can find no
reason that the reverse transformation is not possible. Even if the
reverse transformation could not easily preserve semantics, this kind
of "leaf" transformation could be used for the sole purpose of DDG
extraction for gimple-tuples.


I would like to thank you in advance

Kind regards
Nikolaos Kavvadias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFFYcYQMPiy0tCWlz4RAmDJAJ0S7SjMjJYRgc4tY119yGCJvS5KDwCfc5zN
JMfh0c0TyxFx00513hBYlRk=
=L4P7
-----END PGP SIGNATURE-----