On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote on 04/10/07 02:43:
> 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?
One less thing to think about. That's the only reason, if anyone wants
to work on this from day 1, then great. But since this is easily
fixable afterwards, and we'll already have enough headaches with the
basic conversion, it seemed simpler just to let this be for now.
> 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 ;-)
Absolutely. The advantages are very clear. Location information at
every insn is extremely redundant.
> 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?
Mostly, speed of recognition. I'm not totally against dropping this.
As Andrew M. mentioned during our internal discussions, we will now have
to implement predicates that recognize all the insns in the "GS_COND"
family.
This is something that we can do some experimentation.
Will this replace the tree code class or is it merely sub-classing and
the sub-code
is the real code we have now?
Richard.
