[llvm-dev] Relationship between clang, opt and llc

[Craig Topper via llvm-dev]

If you pass -O0 to clang, most functions will be tagged with an optnone
function attribute that will prevent opt and llc even if you pass -O3 to
opt and llc. This is the mostly likely cause for the slow down in 2.

You can disable the optnone function attribute behavior by passing "-Xclang
-disable-O0-optnone" to clang

~Craig

On Fri, Jan 5, 2018 at 1:19 PM, toddy wang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I tried the following on LULESH1.0 serial version (
> https://codesign.llnl.gov/lulesh/LULESH.cc)
>
> 1. clang++ -O3 LULESH.cc; ./a.out 20
> Runtime: 9.487353 second
>
> 2. clang++ -O0 -Xclang -disable-llvm-passes -c -emit-llvm -o a.bc
> LULESH.cc; opt -O3 a.bc -o b.bc; llc -O3 -filetype=obj b.bc -o b.o ;
> clang++ b.o -o b.out; ./b.out 20
> Runtime: 24.15 seconds
>
> 3. clang++ -O3 -Xclang -disable-llvm-passes -c -emit-llvm -o a.bc
> LULESH.cc; opt -O3 a.bc -o b.bc; llc -O3 -filetype=obj b.bc -o b.o ;
> clang++ b.o -o b.out; ./b.out 20
> Runtime: 9.53 seconds
>
> 1 and 3 have almost the same performance, while 2 is significantly worse,
> while I expect 1, 2 ,3 should have trivial difference.
>
> Is this a wrong expectation?
>
> @Peizhao, what did you try in your last post?
>
> On Tue, Apr 11, 2017 at 12:15 PM, Peizhao Ou via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> It's really nice of you pointing out the -Xclang option, it makes things
>> much easier. I really appreciate your help!
>>
>> Best,
>> Peizhao
>>
>> On Mon, Apr 10, 2017 at 10:12 PM, Mehdi Amini <mehdi.amini at apple.com>
>> wrote:
>>
>>>
>>> On Apr 10, 2017, at 5:21 PM, Craig Topper via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> clang -O0 does not disable all optimization passes modify the IR.; In
>>> fact it causes most functions to get tagged with noinline to prevent
>>> inlinining
>>>
>>>
>>> It also disable lifetime instrinsics emission and TBAA, etc.
>>>
>>>
>>>
>>> What you really need to do is
>>>
>>> clang -O3 -c emit-llvm -o source.bc -v
>>>
>>> Find the -cc1 command line from that output. Execute that command with
>>> --disable-llvm-passes. leave the -O3 and everything else.
>>>
>>>
>>> That’s a bit complicated: CC1 options can be passed through with
>>> -Xclang, for example here just adding to the regular clang invocation `
>>> -Xclang -disable-llvm-passes`
>>>
>>> Best,
>>>
>>> —
>>> Mehdi
>>>
>>>
>>>
>>>
>>> You should be able to feed the output from that command to opt/llc and
>>> get consistent results.
>>>
>>>
>>>
>>>
>>> ~Craig
>>>
>>> On Mon, Apr 10, 2017 at 4:57 PM, Peizhao Ou via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I am wondering about the relationship clang, opt and llc. I understand
>>>> that this has been asked, e.g., http://stackoverflow.com
>>>> /questions/40350990/relationship-between-clang-opt-llc-and-llvm-linker.
>>>> Sorry for posting a similar question again, but I still have something that
>>>> hasn't been resolved yet.
>>>>
>>>> More specifically I am wondering about the following two approaches
>>>> compiling optimized executable:
>>>>
>>>> 1. clang -O3 -c source.c -o source.o
>>>>     ...
>>>>     clang a.o b.o c.o ... -o executable
>>>>
>>>> 2. clang -O0 -c -emit-llvm -o source.bc
>>>>     opt -O3 source.bc -o source.bc
>>>>     llc -O3 -filetype=obj source.bc -o source.o
>>>>     ...
>>>>     clang a.o b.o c.o ... -o executable
>>>>
>>>> I took a look at the source code of the clang tool and the opt tool,
>>>> they both seem to use the PassManagerBuilder::populateModulePassManager()
>>>> and PassManagerBuilder::populateFunctionPassManager() functions to add
>>>> passes to their optimization pipeline; and for the backend, the clang and
>>>> llc both use the addPassesToEmitFile() function to generate object code.
>>>>
>>>> So presumably the above two approaches to generating optimized
>>>> executable file should do the same thing. However, I am seeing that the
>>>> second approach is around 2% slower than the first approach (which is the
>>>> way developers usually use) pretty consistently.
>>>>
>>>> Can anyone point me to the reasons why this happens? Or even correct my
>>>> wrong understanding of the relationship between these two approaches?
>>>>
>>>> PS: I used the -debug-pass=Structure option to print out the passes,
>>>> they seem the same except that the first approach has an extra pass called
>>>> "-add-discriminator", but I don't think that's the reason.
>>>>
>>>> Peizhao
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> 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/20180105/aa003d50/attachment.html>