[llvm-dev] Redefining optnone to help LTO

[Robinson, Paul via llvm-dev]

If we're not storing actual optimization levels (which is Chandler's expressed preference, in the review), and just looking at optnone/not-optnone, then all those questions have straightforward answers (2 & 3 are already things the existing optnone attribute has to deal with).

1) every function would be marked as optnone or not, so there is no concept of a "module" optimization level.
2) inlining is already well-defined for optnone v. not-optnone:
2a) calls made by an optnone function are never inlined except for calls to always_inline functions
2b) optnone functions are always noinline, therefore calls to an optnone function are never inlined
3) optnone functions use FastISel (assuming that's what you meant by "code generator")

--paulr

From: Eric Christopher [mailto:echristo at gmail.com]
Sent: Tuesday, January 17, 2017 5:39 PM
To: Robinson, Paul; llvm-dev at lists.llvm.org; Mehdi Amini
Subject: Re: [llvm-dev] Redefining optnone to help LTO

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170118/3ad2296a/attachment-0001.html>