[LLVMdev] LTO, Code Generation Options, etc

[David Blaikie]

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

> 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>