Resubmit/ping: peephole2 vs cond-exec vs df

[Bernd Schmidt]

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.


Bernd
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: peep2-forward-v6.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100629/545f26f9/attachment.ksh>