Mehdi Amini via llvm-dev
2017-Feb-02 17:38 UTC
[llvm-dev] Register allocator behaves differently when compiling with and without -g
> 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>
Matthias Braun via llvm-dev
2017-Feb-02 18:24 UTC
[llvm-dev] Register allocator behaves differently when compiling with and without -g
> On Feb 2, 2017, at 9:38 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Feb 2, 2017, at 8:20 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto: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# <https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit#>Seeing that doc I also added a sentence that ENABLE_ABI_BREAKING_CHECKS (= different iteration order for hashsets) should not change code generation.- Matthias> > — > 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 <mailto: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 <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/7f7f4de5/attachment.html>
Robinson, Paul via llvm-dev
2017-Feb-02 19:14 UTC
[llvm-dev] Register allocator behaves differently when compiling with and without -g
I made ABI_BREAKING_CHECKS be its own bullet point, and added advice for how to approach "should not change generated code." Maybe that's getting too detailed for this document but it could prevent some false starts. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Matthias Braun via llvm-dev Sent: Thursday, February 02, 2017 10:25 AM To: Mehdi Amini 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 9:38 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Feb 2, 2017, at 8:20 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org<mailto: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#<https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit> Seeing that doc I also added a sentence that ENABLE_ABI_BREAKING_CHECKS (= different iteration order for hashsets) should not change code generation. - Matthias — 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 _______________________________________________ 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 _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/97d3fc8a/attachment.html>