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

[toddy wang via llvm-dev]

@Zhaopei, thanks for the clarification.

@Craig and @Michael, for clang 4.0.1,  -Xclang -disable-O0-optnone gives
the following error message. From which version -disable-O0-optnone gets
supported?

[twang15 at c89 temp]$ clang++ -O0 -Xclang -disable-O0-optnone -Xclang
-disable-llvm-passes -c -emit-llvm -o a.bc LULESH.cc
error: unknown argument: '-disable-O0-optnone'

[twang15 at c89 temp]$ clang++ --version
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu

On Fri, Jan 5, 2018 at 4:45 PM, Craig Topper <craig.topper at gmail.com> wrote:

> 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/82fc0a69/attachment.html>