[llvm-dev] Redefining optnone to help LTO

Mehdi Amini via llvm-dev
Wed, 18 Jan 2017 05:50:33 -0000

Ultimately pushing a much stuff a possible to function attributes makes it the
most natural. Think -ffast-math, -Os, -Oz, or subtargets attributes. Handling
all this stuff at the function level has been proven the easiest to get
straightfoward during LTO, and more flexible for “advanced” use-case when mixing
modes in a single module.

The reasons to not address O1 vs O2 vs O3 is IMO that 1) it is complicated and
2) there isn’t much use-case for this, or I didn’t hear about anyone really
caring a lot about it. So pragmatically, it makes sense to me to try to address
first the low-hanging fruits and to solve what is valuable (I can’t build our
kernel with ThinLTO because we don’t encode -ffreestanding correctly, etc.).

Now, if someone has a great idea on how to handle O1/O2/O3 consistently in a way
that includes LTO, I’m willing to help on the implementation side!

—
Mehdi



> On Jan 17, 2017, at 5:39 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
> Honestly instead of optnone I'd prefer to do something else around
storing optimization levels, but I think the connotations of that in LTO is
going to be painful:
>
> 1) What does it mean to merge two modules of different optimization levels?
> 2) What does it mean to inline two functions of different optimization
levels?
> 3) What code generator should be used?
>
> Etc.
>
> Honestly I think this is a lot of stuff we don't have any good ideas
for and that the current LTO scope doesn't really have. If there's
really a need for it though...
>
> (Also, if we don't want to store the actual optimization levels then
replace "different optimization levels" above with "optnone and
not-optnone" :)
>
> -eric
>
>
> On Wed, Jan 11, 2017 at 8:34 AM Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> In D28404, Mehdi wanted to use the 'optnone' attribute as a way to
record
> "I was compiled with -O0" in the IR, because it seems like a good
idea to
> remember that fact in an LTO compilation and there is no way to remember
> that fact currently.  A couple of people felt it might be better to have
> this idea discussed on the dev list, where it might get better exposure,
> so I'm volunteering to get that discussion started.
>
> While 'optnone' does cause lots of optimizations to bypass a
function,
> exactly matching -O0 was not the motivation and never a hard requirement.
> The implementation makes a distinct effort to get close to the behavior
> of -O0, but it's not an exact match and for the intended purpose
(allowing
> a given function to be un-optimized to help debugging) it worked fine.
>
> Using 'optnone' to convey -O0 to LTO is something of a
redefinition, or
> at least a re-purposing, of the attribute.  To get there from here, I
> think we would need a couple of things to happen, separately from the
> minor grunt work of adding 'optnone' to function IR at -O0.
>
> 1) Update the LangRef definition of 'optnone' to reflect this
intent.
> The current definition doesn't provide a motivation, and the
description
> is (deliberately) a bit vague.  If we want 'optnone' to
intentionally
> match -O0, that should be tightened up.
>
> 2) Make a concerted effort to teach 'optnone' to targets.
Currently
> I know the X86 target is aware of it, but I'm not so sure about others.
>
> 3) Take another look at what 'optnone' currently does *not* turn
off,
> and see if there is something we can do about that.  In some cases this
> will not be practical, and we may just have to live with that.
>
> (Okay, we need 3 things to happen.)
>
> I won't say this is blocking Mehdi's work, but it would remove a
> point of contention and allow the review to proceed more smoothly.
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/7827961d/attachment.html>