Provide better -O0 assembly on request

Eric Christopher echristo at gmail.com
Tue May 19 14:38:04 PDT 2015


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/bfbb1b9c/attachment.html>


More information about the llvm-commits mailing list