[llvm-dev] Redefining optnone to help LTO

[Eric Christopher via llvm-dev]

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