Provide better -O0 assembly on request

[Eric Christopher]

On Tue, May 19, 2015 at 3:42 PM Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

>  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.
>
>
Hmm? Can you show this as a patch? It'll probably make it easier.


> 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.
>
To be clear it's generating them out of order, it's just not the order
you'd expect. Everything is being generated bottom up, so that each
constant is "owned" by the last user rather than the first. (Not that this
matters, that going top down through the function jumps around a bit is
inconvenient for sure).

-eric


>
>
> *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> wrote:
>
> > -----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 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/8e094885/attachment.html>