This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
peep2-forward-v6.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |