[llvm-dev] Relationship between clang, opt and llc
toddy wang via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 9 00:16:11 PST 2018
Sorry,
//mllvm Options can be dumped by clang -v -help -mllvm and clang -v
--help-hidden -mllvm
--> should be
//mllvm Options can be dumped by opt -help-hidden
On Tue, Jan 9, 2018 at 3:12 AM, toddy wang <wenwangtoddy at gmail.com> wrote:
> //mllvm Options can be dumped by clang -v -help -mllvm and clang -v
> --help-hidden
>
> -->
>
> //mllvm Options can be dumped by clang -v -help -mllvm and clang -v
> --help-hidden -mllvm
>
> On Tue, Jan 9, 2018 at 3:09 AM, toddy wang <wenwangtoddy at gmail.com> wrote:
>
>> Thanks, Craig.
>>
>> So, clang -Xclang -disable-llvm-passes actually disables all the LLVM
>> passed populated by clang so that there is no middle-end optimization on bc
>> files.
>>
>> clang -O2 LULESH.c //clang is the driver, invoking cc1, cc1as, ld
>> //options can be passed through to cc1
>> directly.
>> //maybe have different names, e.g.
>> -fvectorize in clang driver and -vectorize-loops in clang -cc1
>> //options are dumped by clang -help
>> and clang --help-hidden
>>
>> clang -cc1 // c/c++ frontend is also referred as clang
>> // this is the c/c++
>> frontend(preprocessor + Lexer + parser) and middle-end ( LLVM-IR optimizer
>> + IR-assembly generator)
>> //controlled by -Xclang <options>,
>> Xclang options dumped by clang -cc1 -help
>> //mllvm Options like -unroll-max count
>> are controlled by -mllvm <options>.
>> //mllvm Options can be dumped by clang
>> -v -help -mllvm and clang -v --help-hidden
>>
>> *//Question: are all mllvm options for
>> middle-end while Xclang options are for front-end?*
>>
>> clang -cc1as // assembly-obj assembler
>> ld/ldd/gold //linker (if -flto is not provided) or
>> link-time optimizer and linker (if -flto -fuse-ld=lld is provided or -flto
>> -fuse-ld=gold is provided)
>>
>>
>> On Tue, Jan 9, 2018 at 2:00 AM, Craig Topper <craig.topper at gmail.com>
>> wrote:
>>
>>> Yes that is what he meant. "-dce, -adce, etc" are command line options
>>> consumed by tools/opt/opt.cpp to give to the PassManagerBuilder that it
>>> creates. The parsing of those options doesn't exist in any of the llvm
>>> library code that is linked into clang. Clang has its own code for
>>> populating a PassManagerBuilder in tools/clang/lib/CodeGen/Backen
>>> dUtil.cpp
>>>
>>> ~Craig
>>>
>>> On Mon, Jan 8, 2018 at 10:55 PM, toddy wang via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Mehdi,
>>>>
>>>> I found -unroll-max-count can be passed w/ -mllvm.
>>>> -dce, -adce, etc, are also dumped by 'opt --help-hidden'. However,
>>>> they cannot be passed w/ -mllvm.
>>>> Is this what "You can't schedule passes this way, only set parameters
>>>> like -unroll-threshold=<uint> etc." means?
>>>>
>>>> [twang15 at c89 temp]$ clang++ -mllvm -unroll-max-count=4 -mllvm -dce
>>>> -save-temps LULESH.cc
>>>> clang (LLVM option parsing): Unknown command line argument '-dce'.
>>>> Try: 'clang (LLVM option parsing) -help'
>>>> clang (LLVM option parsing): Did you mean '-mv4'?
>>>>
>>>>
>>>> On Mon, Jan 8, 2018 at 12:48 PM, Mehdi AMINI <joker.eph at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2018-01-08 8:59 GMT-08:00 toddy wang <wenwangtoddy at gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 8, 2018 at 11:53 AM, Mehdi AMINI <joker.eph at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2018-01-08 8:41 GMT-08:00 toddy wang <wenwangtoddy at gmail.com>:
>>>>>>>
>>>>>>>> Hi Medhi,
>>>>>>>>
>>>>>>>> It seems -mllvm does not work as expected. Anything wrong?
>>>>>>>>
>>>>>>>> [twang15 at c92 temp]$ clang++ -O3 -mllvm *-deadargelim* LULESH.cc
>>>>>>>> clang (LLVM option parsing): Unknown command line argument
>>>>>>>> '-deadargelim'. Try: 'clang (LLVM option parsing) -help'
>>>>>>>> clang (LLVM option parsing): Did you mean '-regalloc'?
>>>>>>>>
>>>>>>>> [twang15 at c92 temp]$ clang++ -O3 -mllvm *deadargelim* LULESH.cc
>>>>>>>> clang (LLVM option parsing): Unknown command line argument
>>>>>>>> 'deadargelim'. Try: 'clang (LLVM option parsing) -help'
>>>>>>>>
>>>>>>>
>>>>>>> You can't schedule passes this way, only set parameters
>>>>>>> like -unroll-threshold=<uint> etc.
>>>>>>>
>>>>>>> Where can I find options like -unroll-threshold=<uint>? I cannot
>>>>>> find it in either opt -help or clang -help.
>>>>>>
>>>>>
>>>>> This one shows up in `opt --help-hidden`. Otherwise in the source code
>>>>> for each transformation.
>>>>> (remember when I mentioned these are intended for LLVM developers and
>>>>> not end-user facing?).
>>>>>
>>>>> --
>>>>> Mehdi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> --
>>>>>>> Mehdi
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -Tao
>>>>>>>>
>>>>>>>> On Mon, Jan 8, 2018 at 11:12 AM, Mehdi AMINI <joker.eph at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2018-01-07 23:16 GMT-08:00 toddy wang <wenwangtoddy at gmail.com>:
>>>>>>>>>
>>>>>>>>>> -mllvm <value> Additional arguments to forward to LLVM's
>>>>>>>>>> option processing
>>>>>>>>>>
>>>>>>>>>> This is dumped by clang. I am not sure what I am supposed to put
>>>>>>>>>> as value in order to tune unrolling/inlining threshold.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As the help says, this is used to pass argument to LLVM itself. If
>>>>>>>>> you remember you earlier question about setA (clang options) and setC (opt
>>>>>>>>> options), this allows to reach setC from the clang command line.
>>>>>>>>> Any option that you see in the output of `opt --help` can be set
>>>>>>>>> from clang using `-mllvm`. Same caveat as I mentioned before: these aren't
>>>>>>>>> supposed to be end-user options.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mehdi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 8, 2018 at 2:02 AM, Sean Silva <chisophugis at gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> For the types of things that you are looking for, you may just
>>>>>>>>>>> want to try a bunch of -mllvm options. You can tune inlining and unrolling
>>>>>>>>>>> threshold like that, for example.
>>>>>>>>>>>
>>>>>>>>>>> On Jan 7, 2018 10:33 PM, "toddy wang via llvm-dev" <
>>>>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Mehdi,
>>>>>>>>>>>>
>>>>>>>>>>>> Now we have 5 pipelines. (In addition to the first 3, which I
>>>>>>>>>>>> have described in detail above, please refer my latest reply for details)
>>>>>>>>>>>> 1. clang + opt + gold
>>>>>>>>>>>> 2. clang + opt + lld
>>>>>>>>>>>> 3. clang + GNU ld/ gold /lld
>>>>>>>>>>>>
>>>>>>>>>>>> 4. clang + opt + llc + clang
>>>>>>>>>>>> clang -emit-llvm -O1 -Xclang -disable-llvm-passes for c/c++ to
>>>>>>>>>>>> .bc generation and minimal front-end optimization
>>>>>>>>>>>> opt for single bc file optimization
>>>>>>>>>>>> llc single bc file to obj file generation and back-end
>>>>>>>>>>>> optimization (no link-time optimization is possible, since llc works on 1
>>>>>>>>>>>> bc file at a time)
>>>>>>>>>>>> clang again for linking all obj file to generate final
>>>>>>>>>>>> executable. (although in principle there can be a link-time
>>>>>>>>>>>> optimization even with all obj files, it requires a lot of work and is
>>>>>>>>>>>> machine-dependent. This may also be the reason why modern compilers like
>>>>>>>>>>>> LLVM/GCC/ICC, etc performs LTO not at obj level. But, obj level may yield
>>>>>>>>>>>> extra benefit even LTO at intermediate level has been applied by compilers,
>>>>>>>>>>>> because obj level can see more information.)
>>>>>>>>>>>>
>>>>>>>>>>>> `clang -Ox` + `opt -Ox` + `llc -Ox` is too coarse-grain.
>>>>>>>>>>>>
>>>>>>>>>>>> 5. Modify clang to align with GCC/ICC so that many tunables are
>>>>>>>>>>>> exposed at clang command line. Not sure how much work is needed, but at
>>>>>>>>>>>> least requires an overall understanding of compiler internals, which can be
>>>>>>>>>>>> gradually figured out.
>>>>>>>>>>>>
>>>>>>>>>>>> I believe 5 is interesting, but 2 may be good enough. More
>>>>>>>>>>>> experiments are needed before decision is made.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 8, 2018 at 12:56 AM, Mehdi AMINI <
>>>>>>>>>>>> joker.eph at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Toddy,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can achieve what you're looking for with a pipeline based
>>>>>>>>>>>>> on `clang -Ox` + `opt -Ox` + `llc -Ox` (or lld instead of llc), but this
>>>>>>>>>>>>> won't be guarantee'd to be well supported across releases of the compiler.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otherwise, if there are some performance-releated (or not...)
>>>>>>>>>>>>> command line options you think clang is missing / would benefit, I invite
>>>>>>>>>>>>> you to propose adding them to cfe-dev at lists.llvm.org and
>>>>>>>>>>>>> submit a patch!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Mehdi
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2018-01-07 21:03 GMT-08:00 toddy wang <wenwangtoddy at gmail.com>
>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot, Mehdi.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For GCC, there are around 190 optimization flags exposed as
>>>>>>>>>>>>>> command-line options.
>>>>>>>>>>>>>> For Clang/LLVM, the number is 40, and many important
>>>>>>>>>>>>>> optimization parameters are not exposed at all, such as loop unrolling
>>>>>>>>>>>>>> factor, inline function size parameters.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I understand there is very different idea for whether or not
>>>>>>>>>>>>>> expose many flags to end-user.
>>>>>>>>>>>>>> Personally, I believe it is a reasonable to keep end-user
>>>>>>>>>>>>>> controllable command-line options minimal for user-friendliness.
>>>>>>>>>>>>>> However, for users who care a lot for a tiny bit performance
>>>>>>>>>>>>>> improvement, like HPC community, it may be better to expose as many
>>>>>>>>>>>>>> fine-grained tunables in the form of command line options as possible. Or,
>>>>>>>>>>>>>> at least there should be a way to achieve this fairly easy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am curious about which way is the best for my purpose.
>>>>>>>>>>>>>> Please see my latest reply for 3 possible fine-grained
>>>>>>>>>>>>>> optimization pipeline.
>>>>>>>>>>>>>> Looking forward to more discussions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jan 7, 2018 at 10:11 AM, Mehdi AMINI <
>>>>>>>>>>>>>> joker.eph at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "SetC" options are LLVM cl::opt options, they are intended
>>>>>>>>>>>>>>> for LLVM developer and experimentations. If a settings is intended to be
>>>>>>>>>>>>>>> used as a public API, there is usually a programmatic way of setting it in
>>>>>>>>>>>>>>> LLVM.
>>>>>>>>>>>>>>> "SetA" is what clang as a C++ compiler exposes to the
>>>>>>>>>>>>>>> end-user. Internally clang will (most of the time) use one or multiple LLVM
>>>>>>>>>>>>>>> APIs to propagate a settings.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Mehdi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2018-01-05 17:41 GMT-08:00 toddy wang via llvm-dev <
>>>>>>>>>>>>>>> llvm-dev at lists.llvm.org>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> 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/20180109/0dd4f3c4/attachment.html>
More information about the llvm-dev
mailing list