This is the mail archive of the
mailing list for the GCC project.
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: PR2912
- From: Richard Henderson <rth at redhat dot com>
- Date: Fri, 25 May 2001 10:46:17 -0700
- Cc: Zack Weinberg <weinberg at cygnus dot com>, gcc at gcc dot gnu dot org
- References: <20010524212258G.email@example.com>
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)
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) && peep2_reg_dead_p (3, operands)