Provide better -O0 assembly on request

[Robinson, Paul]

Hi Sergey,
There's no doubt that fast-isel could do better with debug locations.
The local value map does seem to be one source of problems in this area.
It looks like you are trying the tactic of eliminating the local value 
map entirely.  This has the unfortunate effect of causing fast-isel to 
emit redundant constant loads, which is very sad.

At one time I had tried to improve the bookkeeping in the local value
map to get better debugger behavior, and while it did seem to help there
were still some problems with it, so that patch never made it upstream.

I wonder if a better tactic would be this: Don't attach any debug location
to a local value map instruction at first; this avoids the "random" debug
location problem.  Then when you are finishing up the block, find the first
"real" debug location, and copy it to the first instruction in the block.  
This avoids having the beginning of the block implicitly use the last debug 
location of the physically preceding block, which will usually be wrong too.

What do you think?
--paulr

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Sergey Dmitrouk
> Sent: Monday, May 18, 2015 9:57 AM
> To: llvm-commits
> Subject: Re: Provide better -O0 assembly on request
> 
> Ping (+ attachments with correct names).
> 
> ----
> 
> 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.
> 
> As attached patch for LLVM demonstrates, this is quite easy to achieve.
> 
> Best regards,
> Sergey