Re: VTA RTL patch review?

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug  3, 2009, Richard Henderson <rth@redhat.com> wrote:

> On 07/31/2009 04:32 PM, Richard Henderson wrote:
>> On 07/23/2009 12:56 PM, Alexandre Oliva wrote:
>>> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00256.html
>> ... and ran out of time in sel-sched.c. To be continued...

> There's quite a lot of code in sel-sched.c devoted to
> making sure that blocks consisting of only debug insns
> don't affect scheduling in ways that a non-debug
> compilation wouldn't.

Yeah.  And that's not enough.  sel-sched still causes compare-debug
regressions :-(

> But if that's the case, haven't we already differed
> from non-debug compilation?  Surely empty blocks are
> removed by cleanup cfg?

Yeah, they are, and so are blocks containing only debug insns.

But cleanup cfg doesn't run after scheduling each insn.  The code at
hand is supposed to deal with blocks that would have become empty if
debug insns weren't there, attempting to schedule these debug insns
before anything else.  Unfortunately, there are cases in which
dependencies prevent this, and then otherwise empty blocks remain, and
we diverge.

> Seems to me a better way to handle this is to have
> cleanup cfg notice blocks with just debug insns and
> move the debug insns somewhere else.  Either into the
> predecessor or successor block, depending on what
> seems best -- though I'm not sure it should matter
> either way.

Unfortunately, in the cases in which we diverge, we can't move the insns
to either block.  The predecessors have multiple outgoing edges, and the
successors have multiple incoming edges, so neither block is a valid
option.

I'm trying to avoid just dropping the info on the floor, but actually
fixing this might involve introducing something like cond_exec
var_location insns, and figuring out a condition that can be used to
tell whether to use the newly-bound value or the one that would have
remained in place should the condition not be met.  Then we could emit a
conditional in debug information.

Just dropping the info on the floor is undesirable because it leads to
incorrect debug information, and so does moving the debug insns to a
predecessor or successor that has other successors or predecessors.

-- 
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