[LLVMdev] LTO, Code Generation Options, etc

[Eric Christopher]

On Mon, Mar 30, 2015 at 10:50 AM David Blaikie <dblaikie at gmail.com> wrote:

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

Some, yes, all? Dunno. I was thinking mostly of CGSCC or Module passes in
general. Ideally it'll just be options that turn on/off things like that
though.


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

Yep. Just widening it and giving the whole set of things its own thread.

-eric


>
>> - 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/bb7609a2/attachment.html>