Resubmit/ping: peephole2 vs cond-exec vs df

Richard Henderson rth@redhat.com
Tue Jun 29 18:28:00 GMT 2010


On 06/29/2010 06:22 AM, Bernd Schmidt wrote:
> On 06/29/2010 04:32 AM, Richard Henderson wrote:
>>> length, but that won't always work if we start to match against
>>> partially filled buffers.  It's 2am so I may be blind but I don't see
>>> how it causes more calls into df_simulate or other useless work?  There
>>> should be exactly one such call per insn as it is added to the buffer
>>> (plus any updates necessary after we match something and have to
>>> regenerate life information).  Life information is stored in the buffer
>>> so we don't have to do anything when advancing the buffer start.
>>
>> The case in which we have matches is what I had in mind.  Say the
>> buffer has length 10.  If we fill the buffer then match the first
>> insn, that invalidates the life information for the entire buffer
>> does it not?  In which case we've wasted effort on 9 insns.
> 
> No, those parts of the buffer that weren't part of the match remain
> unaffected, we keep both the insns and their life information.  We only
> rebuild life for the new insns produced by the match.
> 
> Here's a new version with a few more comments and a few remnants of old
> code removed.  I've also removed some dead code found in genrecog.c (got
> sidetracked today into debugging the current peephole2 code again...);
> this was left in after your r34208 patch.
> 
> Bootstrapping now.

Thanks for the extra comments.
Ok if that boot succeeds.


r~



More information about the Gcc-patches mailing list