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

Thanks a lot, it is clear to me now.

BTW, for Clang's slowdown, I submit an issue here:
https://github.com/flang-compiler/flang/issues/356

I have no idea about the root cause.
Maybe due to debug symbols. But, I already use -DCMAKE_BUILD_TYPE=Release.
Anyway, I believe there is a bug somewhere.


On Sat, Jan 6, 2018 at 3:43 PM, Craig Topper <craig.topper at gmail.com>
wrote:
> -disable-O0-optnone has no effect with anything other than -O0.
>
> -O0 being passed to clang also causes all functions to be marked noinline.
> I don't know if there is a command line option to turn that off.
>
> I recommend passing "-O1 -Xclang -disable-llvm-passes" to clang.
Passing
> -O0 very specifically means disable optimizations.
>
> ~Craig
>
> On Sat, Jan 6, 2018 at 12:25 PM, toddy wang <wenwangtoddy at
gmail.com>
> wrote:
>
>> @Craig and @Michael
>>
>> After installing clang-5.0 (download from http://releases.llvm.org,
does
>> not have Flang build's slowdown mention above),
>>
>> 1. clang++ -O0 -Xclang -disable-O0-optnone -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: 2.354069e+01
>>
>> 2. clang++ -O1 -Xclang -disable-O0-optnone -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.046271e+00
>>
>> 3. clang++ -O3 LULESH.cc
>> runtime: 9.118835e+00
>>
>> 4. clang++ -O2 -Xclang -disable-O0-optnone -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.091278e+00
>>
>> 5. clang++ -O3 -Xclang -disable-O0-optnone -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.096919e+00
>>
>> Apparently, clang++ -O0 -Xclang -disable-O0-optnone does not work as
>> expected.
>>
>> The conclusion seems to be  -Xclang -disable-O0-optnone works when
clang
>> optimization level is O1/O2/O3, not O0.
>>
>> Any comments?
>>
>>
>>
>>
>> On Sat, Jan 6, 2018 at 2:30 AM, toddy wang <wenwangtoddy at
gmail.com>
>> wrote:
>>
>>> What I am trying is to compile a program with different sets of
>>> optimization flags.
>>> If there is no fine-grained control over clang optimization flags,
it
>>> would be impossible to achieve what I intend.
>>>
>>> Although there is fine-grained control via opt, for a large-scale
>>> projects, clang-opt-llc pipeline may not be a drop-in solution.
>>>
>>> On Fri, Jan 5, 2018 at 10:00 PM, Craig Topper <craig.topper at
gmail.com>
>>> wrote:
>>>
>>>> I don't think "clang -help" prints options about
optimizations. Clang
>>>> itself doesn't have direct support for fine grained
optimization control.
>>>> Just the flag for levels -O0/-O1/-O2/-O3. This is intended to
be simple and
>>>> sufficient interface for most users who just want to compile
their code. So
>>>> I don't think there's a way to pass just -dse to clang.
>>>>
>>>> opt on the other hand is more of a utility for developers of
llvm that
>>>> provides fine grained control of optimizations for testing
purposes.
>>>>
>>>>
>>>>
>>>> ~Craig
>>>>
>>>> On Fri, Jan 5, 2018 at 5:41 PM, toddy wang <wenwangtoddy at
gmail.com>
>>>> wrote:
>>>>
>>>>> Craig, thanks a lot!
>>>>>
>>>>> I'm actually confused by clang optimization flags.
>>>>>
>>>>> If I run clang -help, it will show many optimizations
(denoted as set
>>>>> A)  and non-optimization options (denoted as set B).
>>>>> If I run llvm-as < /dev/null | opt -O0/1/2/3
-disable-output
>>>>> -debug-pass=Arguments, it also shows many optimization
flags (denote as set
>>>>> C).
>>>>>
>>>>> There are many options in set C while not in set A, and
also options
>>>>> in set A but not in set C.
>>>>>
>>>>> The general question is:  what is the relationship between
set A and
>>>>> set C, at the same optimization level O0/O1/O2/O3?
>>>>> Another question is: how to specify an option in set C as a
clang
>>>>> command line option, if it is not in A?
>>>>>
>>>>> For example, -dse is in set C but not in set A, how can I
specify it
>>>>> as a clang option? Or simply I cannot do that.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 5, 2018 at 7:55 PM, Craig Topper
<craig.topper at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> O0 didn't start applying optnone until r304127 in
May 2017 which is
>>>>>> after the 4.0 family was branched. So only 5.0, 6.0,
and trunk have that
>>>>>> behavior. Commit message copied below
>>>>>>
>>>>>> Author: Mehdi Amini <joker.eph at gmail.com>
>>>>>>
>>>>>> Date:   Mon May 29 05:38:20 2017 +0000
>>>>>>
>>>>>>
>>>>>>     IRGen: Add optnone attribute on function during O0
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Amongst other, this will help LTO to correctly
handle/honor files
>>>>>>
>>>>>>     compiled with O0, helping debugging failures.
>>>>>>
>>>>>>     It also seems in line with how we handle other
options, like how
>>>>>>
>>>>>>     -fnoinline adds the appropriate attribute as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Differential Revision:
https://reviews.llvm.org/D28404
>>>>>>
>>>>>>
>>>>>>
>>>>>> ~Craig
>>>>>>
>>>>>> On Fri, Jan 5, 2018 at 4:49 PM, toddy wang
<wenwangtoddy at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> @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/relationsh
>>>>>>>>>>>>
ip-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/20180106/ed0e09c7/attachment.html>

Why are you using build directions from "flang" which is a fortran
compiler
and maintained by different people than the LLVM/clang community? But then
compiling C/C++ code? Their bug database should be used for filing bugs
against the fortran compiler not a C/C++ compiler issue.

~Craig

On Sat, Jan 6, 2018 at 1:04 PM, toddy wang <wenwangtoddy at gmail.com>
wrote:
> Thanks a lot, it is clear to me now.
>
> BTW, for Clang's slowdown, I submit an issue here: https://github.com/
> flang-compiler/flang/issues/356
>
> I have no idea about the root cause.
> Maybe due to debug symbols. But, I already use -DCMAKE_BUILD_TYPE=Release.
> Anyway, I believe there is a bug somewhere.
>
>
> On Sat, Jan 6, 2018 at 3:43 PM, Craig Topper <craig.topper at
gmail.com>
> wrote:
>
>> -disable-O0-optnone has no effect with anything other than -O0.
>>
>> -O0 being passed to clang also causes all functions to be marked
>> noinline. I don't know if there is a command line option to turn
that off.
>>
>> I recommend passing "-O1 -Xclang -disable-llvm-passes" to
clang. Passing
>> -O0 very specifically means disable optimizations.
>>
>> ~Craig
>>
>> On Sat, Jan 6, 2018 at 12:25 PM, toddy wang <wenwangtoddy at
gmail.com>
>> wrote:
>>
>>> @Craig and @Michael
>>>
>>> After installing clang-5.0 (download from http://releases.llvm.org,
>>> does not have Flang build's slowdown mention above),
>>>
>>> 1. clang++ -O0 -Xclang -disable-O0-optnone -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: 2.354069e+01
>>>
>>> 2. clang++ -O1 -Xclang -disable-O0-optnone -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.046271e+00
>>>
>>> 3. clang++ -O3 LULESH.cc
>>> runtime: 9.118835e+00
>>>
>>> 4. clang++ -O2 -Xclang -disable-O0-optnone -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.091278e+00
>>>
>>> 5. clang++ -O3 -Xclang -disable-O0-optnone -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.096919e+00
>>>
>>> Apparently, clang++ -O0 -Xclang -disable-O0-optnone does not work
as
>>> expected.
>>>
>>> The conclusion seems to be  -Xclang -disable-O0-optnone works when
clang
>>> optimization level is O1/O2/O3, not O0.
>>>
>>> Any comments?
>>>
>>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 2:30 AM, toddy wang <wenwangtoddy at
gmail.com>
>>> wrote:
>>>
>>>> What I am trying is to compile a program with different sets of
>>>> optimization flags.
>>>> If there is no fine-grained control over clang optimization
flags, it
>>>> would be impossible to achieve what I intend.
>>>>
>>>> Although there is fine-grained control via opt, for a
large-scale
>>>> projects, clang-opt-llc pipeline may not be a drop-in solution.
>>>>
>>>> On Fri, Jan 5, 2018 at 10:00 PM, Craig Topper <craig.topper
at gmail.com>
>>>> wrote:
>>>>
>>>>> I don't think "clang -help" prints options
about optimizations. Clang
>>>>> itself doesn't have direct support for fine grained
optimization control.
>>>>> Just the flag for levels -O0/-O1/-O2/-O3. This is intended
to be simple and
>>>>> sufficient interface for most users who just want to
compile their code. So
>>>>> I don't think there's a way to pass just -dse to
clang.
>>>>>
>>>>> opt on the other hand is more of a utility for developers
of llvm that
>>>>> provides fine grained control of optimizations for testing
purposes.
>>>>>
>>>>>
>>>>>
>>>>> ~Craig
>>>>>
>>>>> On Fri, Jan 5, 2018 at 5:41 PM, toddy wang <wenwangtoddy
at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Craig, thanks a lot!
>>>>>>
>>>>>> I'm actually confused by clang optimization flags.
>>>>>>
>>>>>> If I run clang -help, it will show many optimizations
(denoted as set
>>>>>> A)  and non-optimization options (denoted as set B).
>>>>>> If I run llvm-as < /dev/null | opt -O0/1/2/3
-disable-output
>>>>>> -debug-pass=Arguments, it also shows many optimization
flags (denote as set
>>>>>> C).
>>>>>>
>>>>>> There are many options in set C while not in set A, and
also options
>>>>>> in set A but not in set C.
>>>>>>
>>>>>> The general question is:  what is the relationship
between set A and
>>>>>> set C, at the same optimization level O0/O1/O2/O3?
>>>>>> Another question is: how to specify an option in set C
as a clang
>>>>>> command line option, if it is not in A?
>>>>>>
>>>>>> For example, -dse is in set C but not in set A, how can
I specify it
>>>>>> as a clang option? Or simply I cannot do that.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 5, 2018 at 7:55 PM, Craig Topper
<craig.topper at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> O0 didn't start applying optnone until r304127
in May 2017 which is
>>>>>>> after the 4.0 family was branched. So only 5.0,
6.0, and trunk have that
>>>>>>> behavior. Commit message copied below
>>>>>>>
>>>>>>> Author: Mehdi Amini <joker.eph at gmail.com>
>>>>>>>
>>>>>>> Date:   Mon May 29 05:38:20 2017 +0000
>>>>>>>
>>>>>>>
>>>>>>>     IRGen: Add optnone attribute on function during
O0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Amongst other, this will help LTO to correctly
handle/honor
>>>>>>> files
>>>>>>>
>>>>>>>     compiled with O0, helping debugging failures.
>>>>>>>
>>>>>>>     It also seems in line with how we handle other
options, like how
>>>>>>>
>>>>>>>     -fnoinline adds the appropriate attribute as
well.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Differential Revision:
https://reviews.llvm.org/D28404
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ~Craig
>>>>>>>
>>>>>>> On Fri, Jan 5, 2018 at 4:49 PM, toddy wang
<wenwangtoddy at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> @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/relationsh
>>>>>>>>>>>>>
ip-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/20180106/c8f4ae0e/attachment.html>

I have a code written in Fortran but with C/C++ kernels.
So I have to use both Flang and Clang to compile, maybe I should use
LLVM5.0 release for c/c++ and only their Flang for fortran code.
It should work but I have not tried yet.

On Sat, Jan 6, 2018 at 4:19 PM, Craig Topper <craig.topper at gmail.com>
wrote:
> Why are you using build directions from "flang" which is a
fortran
> compiler and maintained by different people than the LLVM/clang community?
> But then compiling C/C++ code? Their bug database should be used for filing
> bugs against the fortran compiler not a C/C++ compiler issue.
>
> ~Craig
>
> On Sat, Jan 6, 2018 at 1:04 PM, toddy wang <wenwangtoddy at
gmail.com> wrote:
>
>> Thanks a lot, it is clear to me now.
>>
>> BTW, for Clang's slowdown, I submit an issue here:
>> https://github.com/flang-compiler/flang/issues/356
>>
>> I have no idea about the root cause.
>> Maybe due to debug symbols. But, I already use
-DCMAKE_BUILD_TYPE=Release
>> .
>> Anyway, I believe there is a bug somewhere.
>>
>>
>> On Sat, Jan 6, 2018 at 3:43 PM, Craig Topper <craig.topper at
gmail.com>
>> wrote:
>>
>>> -disable-O0-optnone has no effect with anything other than -O0.
>>>
>>> -O0 being passed to clang also causes all functions to be marked
>>> noinline. I don't know if there is a command line option to
turn that off.
>>>
>>> I recommend passing "-O1 -Xclang -disable-llvm-passes" to
clang.
>>> Passing -O0 very specifically means disable optimizations.
>>>
>>> ~Craig
>>>
>>> On Sat, Jan 6, 2018 at 12:25 PM, toddy wang <wenwangtoddy at
gmail.com>
>>> wrote:
>>>
>>>> @Craig and @Michael
>>>>
>>>> After installing clang-5.0 (download from
http://releases.llvm.org,
>>>> does not have Flang build's slowdown mention above),
>>>>
>>>> 1. clang++ -O0 -Xclang -disable-O0-optnone -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: 2.354069e+01
>>>>
>>>> 2. clang++ -O1 -Xclang -disable-O0-optnone -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.046271e+00
>>>>
>>>> 3. clang++ -O3 LULESH.cc
>>>> runtime: 9.118835e+00
>>>>
>>>> 4. clang++ -O2 -Xclang -disable-O0-optnone -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.091278e+00
>>>>
>>>> 5. clang++ -O3 -Xclang -disable-O0-optnone -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.096919e+00
>>>>
>>>> Apparently, clang++ -O0 -Xclang -disable-O0-optnone does not
work as
>>>> expected.
>>>>
>>>> The conclusion seems to be  -Xclang -disable-O0-optnone works
when
>>>> clang optimization level is O1/O2/O3, not O0.
>>>>
>>>> Any comments?
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jan 6, 2018 at 2:30 AM, toddy wang <wenwangtoddy at
gmail.com>
>>>> wrote:
>>>>
>>>>> What I am trying is to compile a program with different
sets of
>>>>> optimization flags.
>>>>> If there is no fine-grained control over clang optimization
flags, it
>>>>> would be impossible to achieve what I intend.
>>>>>
>>>>> Although there is fine-grained control via opt, for a
large-scale
>>>>> projects, clang-opt-llc pipeline may not be a drop-in
solution.
>>>>>
>>>>> On Fri, Jan 5, 2018 at 10:00 PM, Craig Topper
<craig.topper at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I don't think "clang -help" prints
options about optimizations. Clang
>>>>>> itself doesn't have direct support for fine grained
optimization control.
>>>>>> Just the flag for levels -O0/-O1/-O2/-O3. This is
intended to be simple and
>>>>>> sufficient interface for most users who just want to
compile their code. So
>>>>>> I don't think there's a way to pass just -dse
to clang.
>>>>>>
>>>>>> opt on the other hand is more of a utility for
developers of llvm
>>>>>> that provides fine grained control of optimizations for
testing purposes.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ~Craig
>>>>>>
>>>>>> On Fri, Jan 5, 2018 at 5:41 PM, toddy wang
<wenwangtoddy at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Craig, thanks a lot!
>>>>>>>
>>>>>>> I'm actually confused by clang optimization
flags.
>>>>>>>
>>>>>>> If I run clang -help, it will show many
optimizations (denoted as
>>>>>>> set A)  and non-optimization options (denoted as
set B).
>>>>>>> If I run llvm-as < /dev/null | opt -O0/1/2/3
-disable-output
>>>>>>> -debug-pass=Arguments, it also shows many
optimization flags (denote as set
>>>>>>> C).
>>>>>>>
>>>>>>> There are many options in set C while not in set A,
and also options
>>>>>>> in set A but not in set C.
>>>>>>>
>>>>>>> The general question is:  what is the relationship
between set A and
>>>>>>> set C, at the same optimization level O0/O1/O2/O3?
>>>>>>> Another question is: how to specify an option in
set C as a clang
>>>>>>> command line option, if it is not in A?
>>>>>>>
>>>>>>> For example, -dse is in set C but not in set A, how
can I specify it
>>>>>>> as a clang option? Or simply I cannot do that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 5, 2018 at 7:55 PM, Craig Topper
<craig.topper at gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> O0 didn't start applying optnone until
r304127 in May 2017 which is
>>>>>>>> after the 4.0 family was branched. So only 5.0,
6.0, and trunk have that
>>>>>>>> behavior. Commit message copied below
>>>>>>>>
>>>>>>>> Author: Mehdi Amini <joker.eph at
gmail.com>
>>>>>>>>
>>>>>>>> Date:   Mon May 29 05:38:20 2017 +0000
>>>>>>>>
>>>>>>>>
>>>>>>>>     IRGen: Add optnone attribute on function
during O0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     Amongst other, this will help LTO to
correctly handle/honor
>>>>>>>> files
>>>>>>>>
>>>>>>>>     compiled with O0, helping debugging
failures.
>>>>>>>>
>>>>>>>>     It also seems in line with how we handle
other options, like
>>>>>>>> how
>>>>>>>>
>>>>>>>>     -fnoinline adds the appropriate attribute
as well.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     Differential Revision:
https://reviews.llvm.org/D28404
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ~Craig
>>>>>>>>
>>>>>>>> On Fri, Jan 5, 2018 at 4:49 PM, toddy wang
<wenwangtoddy at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> @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/relationsh
>>>>>>>>>>>>>>
ip-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/20180106/79b7af2a/attachment-0001.html>