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
