Re: Resubmit/ping: peephole2 vs cond-exec vs df

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Jun 29, 2010 at 6:22 AM, Bernd Schmidt <bernds@codesourcery.com> 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.
>

i386 peephole2 change breaks bootstrap on Linux/x86-64. Also the
comments:

;; After splitting up read-modify operations, array accesses with memory
;; operands might end up in form:
;;  sall    $2, %eax
;;  movl    4(%esp), %edx
;;  addl    %edx, %eax
;; instead of pre-splitting:
;;  sall    $2, %eax
;;  addl    4(%esp), %eax
;; Turn it into:
;;  movl    4(%esp), %edx
;;  leal    (%edx,%eax,4), %eax

no longer applies to the new peephole2 pattern.


-- 
H.J.