Provide better -O0 assembly on request

[David Blaikie]

On Fri, Apr 24, 2015 at 6:58 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com
> wrote:

> Hi,
>
> NOTE: there is an attached patch, but it's to show how it can be achieved
> not
> NOTE: for review, that's why the message is not in llvm-commits.  I'd like
> to
> NOTE: get general opinion on the change.
>
> I've been trying to fix PR13269 (
> https://llvm.org/bugs/show_bug.cgi?id=13269)
> in http://reviews.llvm.org/D9084 as that issue stood in the way of getting
> correct debug locations.  With those changes applied it is better in
> general,
> but for -O0 flag debug locations are still a mess as FastISel is used for
> generating most of code and it doesn't make use of additional information
> from
> SDNodes.
>
> FastISel resets debug locations on materializing constants (see
> http://reviews.llvm.org/rL108302), which is a workaround for issue
> created by
> FastISel by eliminating redundancy for constant emission as it implies
> instruction reordering and basically shuffled order of debug locations.
>
> Workaround from r108302 mentioned above fails in the way that some
> instructions
> are assigned debug locations of completely unrelated code lines (see
> attached
> "bad" files right after prologue).
>
> Not resetting debug locations of instructions for constants partially
> fixes it
> although leads to worse debugging experience, but still some auxiliary
> code like
> that for register spilling will be marked with almost random debug
> locations.
>
> The best (in the sense of "most readable" and "easy to debug") assembly is
> produced with disabled local value optimization and intact debug locations
> (see
> "good" files in the attachment).
>
> I'd like to propose adding a way to produce this "debuggable" assembly on
> request via additional option in Clang.  It could be enabled on -g3 or
> maybe we
> could introduce -g4, although -g2 and -g3 currently seem to be equivalent
> to
> -g (-g1).  Or some other way if anyone has better idea.
>

Having a debug mode that changes the object code is a pretty hard line we
haven't crossed yet. There's been some mention of -Og which would optimize
for debuggability, which would be totally fine to affect codegen, but I
don't know if this change would fit there either.

It'd be best to try to find a solution that doesn't adversely affect code
generation. Paul's suggestion (or something that produces the equivalent
behavior - essentially attribute the constant manifesting instructions to
whatever the first debug-located instruction is in the basic block) is one
option. Another would be to change the way these constants are emitted,
sinking them down at least to their first use, and attributing them to that
use. I haven't looked at the code enough to know how this would work/be
implemented.

 - David


>
> As attached patch for LLVM demonstrates, this is quite easy to achieve.
>
> Best regards,
> Sergey
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150518/d77ae2ee/attachment.html>