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


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

Re: PR2912


On Thu, May 24, 2001 at 09:22:58PM -0700, Mark Mitchell wrote:
> The problem is that these peepholes fall afoul of what looks to be an
> undocumented restriction on peepholes: they must not change the set of
> live registers.

Not so much "undocumented" as "if you do this you've made a mistake".

> The new peepholes get rid of instructions we don't need that mess
> with `al' and `dl' -- and thereby make those registers no longer killed.

Um.. this makes no difference.

If a register is set in a block, there are two possibilities:
it is used in some subsequent block, or it is used locally.
For peepholes, we are only interested in the later.  If the
register does not die within the set of source instructions,
then we cannot remove the set of the register.


For this test case, with the fall off the end of the function,
the register isn't actually used, but we can't tell that from
within the peephole.  The "unreturned" return value should have
been clobbered by

(insn 1011 1009 1012 (clobber (reg/i:SI 0 eax)) -1 (nil)
    (nil))

but that instruction was deleted during the .23.flow2 dump.
I'm not sure why.  But that's immaterial to the bug, which is
that the peephole condition should include

  peep2_reg_dead_p (3, operands[7]) && peep2_reg_dead_p (3, operands[8])


r~


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