Re: GIMPLE issues and status of gimple-tuples

[Nikolaos Kavvadias <nkavv at physics dot auth dot gr>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Diego Novillo wrote:

> 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;
>
>>
> Better how? Faster compile times? Reduced memory utilization?
> More opportunities for optimization? Compared to what baseline?

I believe it can be helpful in the following ways:

a. have only one form of if-stmts
b. it is straightforward to extract DDGs for such lowerized GIMPLE IR
than with if-stmts incorporating arbitrary compound-stmts
c. this would be only complementary and not to substitute current
GIMPLE IR:

"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."

I repeat that there is no need in applying transformations on this
LOWERED GIMPLE on formation of "real" three-address-code for
machine-dependent optimizations. Only for DDG extraction on tuples
(symbolic opcode with 1 destination and 2 source addresses and
subforms there of) which would be made available by an analysis and
not optimization pass.

Thus, not better in any other way (compiler times etc). That's way i
propose this as a "leaf" transformation made by an analysis (i.e.
creating and working on a copy of the GIMPLE IR of a program) pass and
not an actual optimization pass.


>> 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).
>>
> The gimple-tuples branch is exclusively a data structure
> rearrangement to reduce the memory footprint taken by GIMPLE. We
> are not going to change the IR in any significant way.


OK.

>
>> Also: gimple-tuples focuses more on low-GIMPLE right?
>
>>
> No. It focuses exclusively on the data structures we use to
> represent the IR.
>
>> if-stmt : COND_EXPR op0 -> condition op1 -> compound-stmt op2 ->
>> compound-stmt
>>
> This would be for what we've come to known as High GIMPLE. The
> documentation for Low GIMPLE is a bit lacking. It's mostly
> documented in source code comments.
>
>
Maybe the current low GIMPLE is already there. So there is no doc
update for these features, at least for a BNF-like grammar? (as in the
current gccint). I'll read all *gimpl* files :)

Kind regards
Nikolaos Kavvadias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFFYc1pMPiy0tCWlz4RAis4AKCqXC8E/QPobOHIR7J316EYLJPGWwCgtNEw
kMRLnGMI4ybz7Sw+xvXtJko=
=gGRG
-----END PGP SIGNATURE-----