[LLVMdev] LTO, Code Generation Options, etc

David Blaikie dblaikie at gmail.com
Mon Mar 30 10:50:17 PDT 2015

On Mon, Mar 30, 2015 at 9:52 AM, Eric Christopher <echristo at gmail.com>

> From PR18808 I said a few things and that I was going to redirect to the
> mailing list for further discussion. So here we are, go.
> 1) Whether or not to allow changing of target-cpu/target-feature/triple at
> link time code generation.
> - Not convinced here of the facility to do so. Could just recompile the
> individual bitcode files to get what you want, but there are some users
> that are trying to ship bitcode (as crazy as that sounds).
> 2) How to pass other sorts of options to the backend for code generation
> - -ffoo options -fno-foo options. I.e. -fno-inline, etc. I think this is
> really pretty important from the user POV. It affects things at a more
> global level.

I assume many of these still could/should be function-specific attributes,
no? (it seems like there's a logical interpretation of compiling one object
file with -fno-inline and another without it - the same as having
__attribute__((noinline)) on the functions of the first object and not on
those of the second - this may not apply to other options, but perhaps
there's a better example of options we should think about here that don't
have a per-function interpretation?)

> 3) The llvm developer debugging story

Was this the thing Duncan was talking about/proposing on llvmdev a few
weeks ago? Something about command line overridable options, etc? (I can
try to find the thread if that doesn't sound familiar)

> - It's useful for llvm developers to be able to more accurately debug a
> set of IR using bisection or being able to turn off code generation
> options. Should this be done at the command level (i.e. infrastructure that
> clang and llc etc could even share), or should it be done at an llvm IR
> rewriting level? Don't know. I kind of want a rewriter, but I'm not wedded
> to any particular answer.
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150330/6cc0dd91/attachment.html>

More information about the llvm-dev mailing list