[PATCH] D94542: [X86] Default to -x86-pad-for-align=false to drop assembler difference with or w/o -g

Thu Jan 14 20:16:04 PST 2021

dblaikie added a comment.

In D94542#2500058 <https://reviews.llvm.org/D94542#2500058>, @reames wrote:

> I'm not convinced that disabling these optimizations is warranted.  I'm not actively opposing the patch, just want to list my concerns for the record.
>
> As a general matter, -O3 -g means "perform optimization while preserving the best debug experience we can", not "strictly w/o reducing debug quality optimize as best as possible".  We have numerous places in the optimizer that we perform optimizations that destroy debug information.  We also have lots of places - one use restrictions which haven't been audited for instance - where the presence of debug info restricts optimization.  We treat the later as bugs, not the former.
>
> It's not clear to be me why this particular optimization should be disabled just because it happens to emit different code w/ and w/o debuging enabled.
>
> The bug (https://bugs.llvm.org/show_bug.cgi?id=42138) that triggered this review appears to be an automated testing framework.  I fully understand the value of that type of automatic bug discovery, but when the framework reports something which is not a bug, the framework should be fixed.  I believe this is a bug in the reporting framework, not the assembler.

Admittedly I don't fully understand this bug (I'd /love/ a concrete, small example (short assembly file, few command lines) showing how an extra label (happy for the test not to contain full/complete DWARF, I'll happily believe the extra labels needed to describe scopes, variable locations, etc)), but it is pretty important that turning on debug info does not change the generated machine code - otherwise there's the chance of heisenbugs.

If this is a case where enabling debug info changes the selected machine code, that is a bug and one worth fixing one way or another. If the optimization can't be performed in the presence of extra labels, that's something we should figure out - perhaps there's some way to allow the relaxation even in the presence of the labels & cause the labels to be elided/removed, degrading debugging in some way. But that sounds... complicated. If those backing the optimization aren't willing to sign up to do that work, then I think it's plausible to suggest that the optimization isn't feasible to add at this time.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94542/new/

https://reviews.llvm.org/D94542