This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: peephole vs RTX_FRAME_RELATED_P


On Mon, Dec 19, 2005 at 02:11:46PM -0800, Ian Lance Taylor wrote:
> I think an algorithm which should work fairly reliably in the general
> case is:
> 
>   1) Are there any old insns with RTX_FRAME_RELATED_P set?
>      If no, stop.
>   2) For each old insn with RTX_FRAME_RELATED_P set:
>      a) if insn has a REG_FRAME_RELATED_EXPR note, add it to the list;
>      b) otherwise, insn should be a PARALLEL or SEQUENCE or SET;
>         add the insn to the list.
>   3) Set RTX_FRAME_RELATED_P on last new insn.
>   4) If there is more than one entry on list, turn it into a PARALLEL
>      (see dwarf2out_frame_debug_expr).  Otherwise take first insn on
>      list.
>   5) Put the result of 4 in a REG_FRAME_RELATED_EXPR note on last new
>      insn.

I think that this is all complicated enough that we should
simply deny peepholing insns with RTX_FRAME_RELATED_P set.

You'll note, for instance, that while we got results that
were partially correct in the transformation, in that we
recoginize that the cfa is at offset 16, we don't recognize
that we shouldn't be generating a store of reg 0 in the 
state machine.

In the specific instance here, where we'd like to use the
push for space savings, we can simply generate it that way
to begin with, with the appropriate REG_FRAME_RELATED_EXPR
indicating that it's merely a stack adjustment.



r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]