llvm dev - Jan 2018 - Relationship between clang, opt and llc

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/36760b5e/attachment.html>

@Toddy, I think I had some misunderstanding about the Clang command line
options when I posted the question.

I think pipeline 1 and 3 are supposed to have only trivial difference,
while pipeline 2 is supposed to be much slower than the other two because
the "-O0" option in pipeline 2 can disable some of the important
passes in
opt (even if you use "-O3" with opt).

I tried to check the IRs generated by pipeline 2 and 3 and saw that they
are not the same (e.g., pipeline 3 emits IR with more alias info that can
be used in opt). And what I did was exactly pipeline 2 (mistakenly thinking
it would be equivalent to pipeline 1). So from my understanding, if you
want to use the clang-opt-llc pipeline, you may need to stick with pipeline
3, where the "-O3 -Xclang -disable-llvm-passes" options tell clang to
generate unoptimized IR that can be later fully optimized as in "clang
-O3"
directly.

On Fri, Jan 5, 2018 at 1:19 PM, toddy wang <wenwangtoddy at gmail.com>
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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180105/0b40247b/attachment-0001.html>

2018-01-05 22:19 GMT+01:00 toddy wang via llvm-dev <llvm-dev at
lists.llvm.org>:
> 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
clang -O0 adds a "optnone" attribute to each function that causes most
optimization passes to skip that function. Avoid with "-Xclang
-disable-O0-optnone".

Michael

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>