This is the mail archive of the
mailing list for the GCC project.
>>>>> "Richard" == Richard Henderson <firstname.lastname@example.org> writes:
Richard> On Thu, May 24, 2001 at 09:22:58PM -0700, Mark Mitchell
>> 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.
Richard> Not so much "undocumented" as "if you do this you've made
Richard> a mistake".
I guess the point is that I looked at the `define_peephole2' and then
I looked at the manual, and I didn't see why the definition was wrong,
so that means either I was dumb or the manual wasn't good enough. I'm
willing to believe either alternative.
>> 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.
Richard> Um.. this makes no difference.
What happenned is that we propogated the fact that LIVE_AT_END
contained %eax (because it was live on entry to the successor blocks).
Then, we noticed that `%al' was set in the block, so me made `%eax'
not live at block start. Then, we removed the set of `%al' in the
peephole. Then, we verified our information and found that now `%eax'
was still live at block start, which was different than what we
expected, so we aborted.
OK, I see what you're saying -- you're saying that it's bogus to
remove the set of `%al' because we don't know how else `%al' might be
used after this point. That makes sense.
Richard> peep2_reg_dead_p (3, operands) && peep2_reg_dead_p
Richard> (3, operands)
Would you mind removing my patch (which I guess perpetuates the bug in
the original peephole, but makes it not crash us) with yours? I'm in
the air very shortly, so I won't get a chance to run another test
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com