[PATCH] D67385: Pass -mcmodel to LTO plugin

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen added a comment.

In D67385#1680959 <https://reviews.llvm.org/D67385#1680959>, @tejohnson wrote:

> In D67385#1680942 <https://reviews.llvm.org/D67385#1680942>, @khchen wrote:
>
> > @tejohnson for example:
> >
> >   $ clang -flto a.c -c -o a.o
> >   $ llvm-ar q a.a a.o          // archive libraries      
> >   $ clang -flto a.a b.c -O2 -o main -mcmodel=small 
> >
> >
> > In above case user need to aware that passing `-Wl,-plugin-opt=-code-model=small` to plugin is necessary.
> >  It seems to me that is inconvenience because I believe user doesn't know it.
>
>
> In general, -flto should be transparent to the build process. Think about what happens in your example if you remove -flto:
>
> $ clang a.c -c -o a.o
>  $ llvm-ar q a.a a.o          // archive libraries      
>  $ clang a.a b.c -O2 -o main -mcmodel=small
>
> a.o will be a native code built with the default mcmodel and -O0.
>
> Generally, adding -flto shouldn't change this - I would argue that it would be unexpected to apply mcmodel=small as the user chose to compile a.c with the default mcmodel. We are going more and more toward a model where info is communicated via the IR from the compile step, as the mcmodel already is. Is there a compelling reason why a.c should not get the default mcmodel in this case (without having compiled it mcmodel=small in the first place)?


Because this library (a.c) is provided by another user/developer.
But you are right, if -flto should be transparent to the build process, user should be aware that.

>> I think this case is similar to if a user has a bitcode library compiled with -O2 or -Oz, and link a program with -O3 -flto, what is expected behavior for user?
> 
> There are a few things that are passed through the link command line to the plugin for legacy reasons, including -O2/-O3. However, note that in your above example the -O2 will not cause a.o to be O2 <https://reviews.llvm.org/owners/package/2/> optimized: a.c is built at -O0 and this is encoded in the IR via function attributes (noinline and optnone), so the functions will not get O2 <https://reviews.llvm.org/owners/package/2/>/O3 <https://reviews.llvm.org/owners/package/3/> optimizations like inlining, etc.

Got it, that's helpful.
Thanks for your time and effort.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67385/new/

https://reviews.llvm.org/D67385