[PR debug/45136] revamp handling of BB boundary debug insns in sched

Alexandre Oliva aoliva@redhat.com
Wed Jan 19 23:03:00 GMT 2011


Ping^2?

On Nov 30, 2010, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Sep  4, 2010, Alexandre Oliva <aoliva@redhat.com> wrote:

>> We used to mark and skip debug insns at beginning and end of basic
>> blocks during sched initialization, so as to leave them alone along with
>> any notes that might appear between them and non-debug insns, because in
>> a compilation without debug insns, the notes would remain in place for
>> being outside the blocks.

>> This worked pretty well, except when multi-block sched happened to pull
>> an insn from a later block, causing a debug insns (and notes between
>> them and other insns) to become boundary insns.  We wouldn't
>> re-recognize them as boundary insns or notes, so we'd end up moving the
>> notes about, whereas the non-debug compilation would leave them in
>> place, causing -fcompare-debug differences.

>> This patch does away with the notion of boundary debug insns and notes.
>> Instead, whenever we're skip boundary notes and we find debug insns, we
>> search further for notes and move them past the debug insns, so that
>> they're left alone by the scheduler, as they would in a non-debug
>> compilation.

>> There are two catches:

>> - if notes ever become meaningful among debug insns, this will kind of
>> change their meaning.  I suppose we can cross that bridge when we get to
>> it.

>> - if there's a long chain of debug insns at the beginning or end of a
>> block, we'll iterate over all of them looking for notes every time we
>> call get_ebb_head_tail for such blocks.  I'm not sure this could become
>> a performance issue, and I don't quite see how to avoid checking it
>> every time, considering that the status of a debug insn may change from
>> one call to another, without changes to a previously checked boundary
>> debug insn, e.g.:

>> (debug_insn 51 ...
>> (note 52 ...
>> (insn 53 ...
>> (debug_insn 55 ...
>> (note 54 ...
>> end of block

>> say the patch moved note 54 past debug_insn 55, so debug_insn 55 is
>> regarded as the scheduling boundary.  Then, sched moves insn 53 to an
>> earlier block.  Now, we have to move note 52 past debug_insn 55, but if
>> we optimized the search at the end of the block to stop at debug_insn
>> 55, we'd miss the change of status of note 52 and debug_insn 51.

>> Thoughts?

>> This patch was regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu.
>> Ok to install?

> This no longer bootstrapped recently.  The symptom was moving a
> NOTE_INSN_FUNCTION_BEGIN out of block 2, so that the debug dumps would
> no longer match the debug dumps, in which the note was still at the end
> of block 2.

> I couldn't quite figure out why in some cases notes are moved out of
> blocks, and in other cases they aren't, so I ended up just punting at
> it, removing block numbers from all notes before the final dump.

> Better suggestions are welcome.

> This was again regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu.
> Ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-sched-push-notes-out.patch
Type: text/x-diff
Size: 7348 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110119/5ea60359/attachment.bin>
-------------- next part --------------


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


More information about the Gcc-patches mailing list