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