Provide better -O0 assembly on request

[David Blaikie]

On Mon, May 18, 2015 at 1:53 PM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com
> wrote:

>
> Hi Paul,
>
> On Mon, May 18, 2015 at 12:04:17PM -0700, Robinson, Paul wrote:
> > 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.
>
> I understand that, but emitting redundant loads is the only way to get
> correct locations in *all* cases.  GCC does this for -O0 and assembly it
> generates matches source code really closely.
>

Yep - there are competing uses of -O0 though, one is "fast compile time"
the other is "debugging accuracy" and so we can't make changes to -O0 that
might hurt compile time (or even executable performance) at -O0 without
some consideration for those use cases. Since this would be a strict
regression in code size (& thus, indirectly performance) it might be a hard
sell to make for -O0. (& not appropriate for -gN, unfortunately)


>
> > 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?
>
> This would be a decent improvement on its own, I think I'll try to do this.
> It solves the actual issue I'm fighting here.  I just thought that more
> generic solution might be of interest, but this should do it for this case.
> Thanks!
>
> --
> 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/d47f2e69/attachment.html>