On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Thoughts/comments on the proposal?
This looks a lot like the RTL insn! For locus, you can use just an "int" instead of a word if you use the same representation for locations as we do for RTL (INSN_LOCATOR). You mention this step as "straightforward to implement" after the conversion to tuples is complete. Why did you decide not to just use the scheme right from the start? There are at least two advantages to this: You can use the same locator information in GIMPLE as in RTL, which saves a conversion step; and you free up 32 bits on 64-bits hosts, which is nice when you add the inevitable so-many-bits for flags to the GIMPLE tuples ;-) I don't really like the idea for promoting subcodes to first-level codes, like you do for GS_COND NE and EQ. Looks complicated and confusing to me. What is the benefit of this? Looks like a nice document overall. I hope we can keep it up to date, it's a good start for new-GIMPLE documentation ;-) Gr. Steven
