Provide better -O0 assembly on request

[Robinson, Paul]

> -----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.
--paulr

> 
> --
> Sergey
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits