[llvm-dev] Register allocator behaves differently when compiling with and without -g

[Stephen Rogers via llvm-dev]

Turns out this was being caused by our own pre-register allocation
instruction scheduler. The debug information caused calls to
LiveIntervals::handleMove to be ordered slightly differently. This change
meant a range of slot indexes had to be renumbered.

I'm curious though. Despite the order of instructions being identical in
both cases, the weights assigned to virtual registers was changed by the
different slot indexes. Why does the register allocator use the absolute
values of the slot indexes in this way when they don't seem to correspond
directly to the structure of the incoming code?

Thanks,
Stephen

On 2 February 2017 at 17:03, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I remember running into cases where –g introduces pseudo-instructions for
> .cfi-* directives, and these become scheduling barriers and therefore
> affect the final code a bit; I don't remember anything about register
> allocation being affected, though.
>
> A reproducer would be awesome.
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Adrian
> Prantl via llvm-dev
> *Sent:* Thursday, February 02, 2017 8:46 AM
> *To:* David Blaikie
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Register allocator behaves differently when
> compiling with and without -g
>
>
>
>
>
> On Feb 2, 2017, at 8:20 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> The goal/intent is that debug info does not affect code generation. There
> are (many?) bugs. I think Apple folks (cc'd Adrian) may be looking at this
> a bit recently, not sure.
>
> The fixes aren't usually too invasive (usually involve something counting
> instructions where it needs to skip counting debug intrinsics), if you're
> interested in having a go at fixing it yourself & sending a patch for
> review.
>
>
>
> Just wanted to add, if you are not able to fix it yourself, it would also
> be helpful if you could file a PR with a testcase.
>
>
>
> -- adrian
>
>
>
>
>
> On Thu, Feb 2, 2017 at 8:18 AM Stephen Rogers via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> In several of our tests, I have noticed that the register allocator
> allocates to virtual registers in a different order when compiling with the
> clang option -g. Before entering the register allocator, the code is
> identical when compiling with and without -g (with the exception of "
> DBG_VALUE" instructions). The only difference I can see is the value
> assigned to the slot index for each instruction. As an example, without -g
> a snippet of a basic block looks like this:
>
> 32B        %vreg29<def> = LDImm 1; REG1:%vreg29
> 36B        %vreg44<def> = LDImm 1103515245; REG1:%vreg44
> 40B        %vreg143:vsub32_1<def,read-undef> = LDImm 0; REG2:%vreg143
> 44B        %vreg68<def> = LDImm 12345; REG1:%vreg68
> 64B        %vreg143:vsub32_0<def> = COPY %vreg143:vsub32_1; REG2:%vreg143
> 72B        %vreg78<def> = LDImm 32; REG1:%vreg78
>
> But when I specify -g, this becomes:
>
> 32B        %vreg29<def> = LDImm 1; REG1:%vreg29 dbg:path/to/source:9:34 @[
> path/to/source:25:13 ]
> 36B        %vreg44<def> = LDImm 1103515245; REG1:%vreg44
> dbg:path/to/source:9:34 @[ path/to/source:25:13 ]
> 44B        %vreg143:vsub32_1<def,read-undef> = LDImm 0; REG2:%vreg143
> 48B        %vreg68<def> = LDImm 12345; REG1:%vreg68
> dbg:path/to/source:9:47 @[ path/to/source:25:13 ]
> 56B        %vreg143:vsub32_0<def> = COPY %vreg143:vsub32_1; REG2:%vreg143
> 60B        %vreg78<def> = LDImm 32; REG1:%vreg78
>
> This change seems to affect the weight assigned to the LiveIntervals for
> each virtual register which in turn changes the allocation order.
>
> It would be my expectation that LLVM should generate identical code for a
> source file with and without debug information enabled. Is it possible we
> are missing some hook in our target backend that would prevent this? Or is
> this the expected behaviour in LLVM?
>
> Thanks,
>
> Stephen
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/2089f603/attachment.html>