Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[Jeff Law <law@redhat.com>]

On 06/25/14 02:54, Richard Sandiford wrote:
>>
>> and the code now uses "rtx_insn *" in hundreds of places where it would
>> previously have used "rtx".
>
> This looks really good to me FWIW.  The only thing I'm not sure about is
> how useful rtx_nonjump_insn would be.  ISTM that jump_insn and call_insn
> really are subclasses that add extra information on top of a "normal"
> insn (JUMP_LABEL for jumps and CALL_INSN_FUNCTION_USAGE for calls).
Glad you think so -- I hope others chime in as the work progresses so 
they're not saying WTF, why did all this change when I approve the 
massive patchkit.


>
> I suppose there's also a bikeshed argument about whether "rtx_"
> should be in the name, if we want to keep open the option of
> moving to a different structure.
Well, as you're probably aware, I hate the "everything is an RTX" model 
we've got in GCC.  I'm not aware of anything having the toplevel objects 
in the insn chain buys us other than bugs.

>
> What do you think about adding something like:
>
>    /* Account for the NEXT_INSN and BLOCK_FOR_INSN fields.  */
>    rtunion GTY ((skip)) fld[2];
>
> to rtx_insn, and similarly for the derived classes, so that each derived
> class has the right size?  It might even help the compiler prove that it
> can speculatively fetch later parts of the structure before a condition
> based on something like BLOCK_FOR_INSN.
For objects which form the insn chain, I'd like the prev, next which 
each object must have would be in the base object.

> Do you get to the point where things like NEXT_INSN and PREV_INSN can
> require rtx_insns as argument?  I suppose that would be the end goal.
> Same for JUMP_LABEL requiring an rtx_jump_insn, etc.
Yea, I think that's the ultimate goal of this stage.  In my mind I 
wanted to narrow the scope enough that it had a chance to get into the 
upcoming release -- thus I've asked David to  focus on the objects that 
show up in the insn chain.  There may be some bleed out, but that's 
really the focus and if we could get to NEXT_INSN/PREV_INSN requiring an 
rtx_insn argument, then we'd be golden.

>
> SEQUENCE is just weird though :-)  It would be good to have an alternative
> representation, but that'd be a lot of work on reorg.
Yea.  And I don't think anyone is keen on rewriting reorg.

Jeff