[llvm] r265762 - Don't IPO over functions that can be de-refined

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 12 15:41:34 PDT 2016


> On Apr 11, 2016, at 1:13 AM, Benjamin Kramer via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> On Fri, Apr 8, 2016 at 8:12 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
>> 
>> Benjamin Kramer wrote:
>>> $ cat foo.cc
>>> inline void foo(const char *, ...) {}
>>> 
>>> int main() {
>>>   foo("bar");
>>> }
>>> 
>>> $ clang-old -S -o - log.cc -O2|grep -c bar
>>> 0
>>> $ clang-new -S -o - log.cc -O2|grep -c bar
>>> 1
>>> 
>>> Is this something we want to fix or is that how it's supposed to work
>>> now. GCC happily discards foo() here.
>> 
>> This is a correct optimization that the old LLVM did for the wrong
>> reasons.  What most likely happened in the old LLVM was we'd infer
>> readnone on foo() and then elide the readnone call to foo in main.
>> Now the first step isn't happening anymore, because it is unsound.
>> 
>> If this specific case is important to you, there probably are things
>> we can do get the above optimization (e.g. inlining through simple
>> varargs functions).  If this can wait, then whatever we do to win back
>> non-inlining IPO for normal C++ inline function should kick in here
>> as well.
> 
> It's not a high priority and can wait, I was just curious if this was
> intentional
> and if so if we have plans to recover the missed optimization. Improving
> non-inlining IPO sounds good :)

The problem is that we don't have a good path forward to improve "non-inlining IPO" that I heard of :(

It seems that adding the keyword "inline" on a function will now inhibit optimizations, which is not what a user would expect when adding "inline".

-- 
Mehdi



More information about the llvm-commits mailing list