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

[Stephen Rogers via llvm-dev]

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>