llvm dev - Feb 2017 - Register allocator behaves differently when compiling with and without -g

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/5c194435/attachment.html>

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/a4689406/attachment.html>

> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/93af3289/attachment.html>

> On Feb 2, 2017, at 8:20 AM, David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org> 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.
I added a line there:
https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit#

— 
Mehdi


> 
> On Thu, Feb 2, 2017 at 8:18 AM Stephen Rogers via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/a54b0db8/attachment.html>