Provide better -O0 assembly on request

[Robinson, Paul]

Which leads me back to the previous suggestion: Leave the local-value handling in place, but generate those instructions without debug-locations; then after the block is finished, attach the first non-null debug loc to the first local-value instruction.  There should already be a pointer to either the last local-value instruction or the first non-local-value instruction, which should make finding the debug loc to use reasonably cheap.
It's pedantically incorrect, but FastISel is generating those instructions out-of-order which is unexpected for –O0, and explicitly attaching the local-value instructions to the first "real" statement should be a happier debugging experience.
--paulr

From: Eric Christopher [mailto:echristo at gmail.com]
Sent: Tuesday, May 19, 2015 2:38 PM
To: Robinson, Paul; Sergey Dmitrouk; David Blaikie
Cc: llvm-commits
Subject: Re: Provide better -O0 assembly on request


On Tue, May 19, 2015 at 2:34 PM Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu<mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-<mailto:llvm-commits->
> bounces at cs.uiuc.edu<mailto:bounces at cs.uiuc.edu>] On Behalf Of Sergey Dmitrouk
> Sent: Monday, May 18, 2015 2:08 PM
> To: David Blaikie
> Cc: llvm-commits
> Subject: Re: Provide better -O0 assembly on request
>
> > 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.
>
> Yeah, -Og is somewhere between -O0 and other levels, not sure it should
> be more debuggable than -O0.

BTW agreeing with David.  I did mean to say changing object code under -g*
shouldn't happen in my previous reply but somehow didn't actually say it.

My personal opinion about -Og is that it should basically be -O1 (that's
what gcc does, in effect).  But we don't want to regress -O0.

>
> > 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.
>
> Solution that doesn't affect code generation a lot is fine with me, just
> was
> curious if anyone is interested in -O0 assembly with less optimizations.
> Second option sounds like a better approach than block post-processing
> to fixup initial location, for now I don't see why it won't work, but need
> to actually try this.  Thanks!

Hmmmm sinking the instructions to the first use... I haven't looked at the
bookkeeping in FastISel for a while so not sure whether this would add more.

There's a vaguely related problem where sometimes it looks like FastISel
pre-loads so many local values that it needs to *spill and reload* some due
to register pressure.  (It would be cheaper to rematerialize the value...)
Maybe sinking values to the first use would help with that, although it
would likely make register-in-use bookkeeping more complicated.

It's not particularly easy given the bottom up nature of fast-isel, at least not without impacting compile time even more.

FWIW removing the local map is going to cause regressions in two places: compile time and execution time. While we don't "care" whether or not execution time at O0 is fast or not, we do care at least some and this would be pretty annoying. The compile time impact is less clear, when we added the map it helped a bit, but I don't know how much it helps today.

I'm not sure there are any particularly good solutions given the tradeoffs here.

-eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150519/1b7ee40f/attachment.html>