[LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)

[Akira Hatanaka]

On Fri, Nov 14, 2014 at 1:58 PM, Eric Christopher <echristo at gmail.com>
wrote:

> Hi Akira,
>
> This is very closely related to the work I've been doing and so I care
> quite a bit about it. I've implemented some of this - at least as far as
> the global TargetMachine options in the current work for Subtarget code
> generation - which is what some of this comes down to. I'll respond inline
> here:
>
> On Thu Nov 13 2014 at 4:35:08 PM Akira Hatanaka <ahatanak at gmail.com>
> wrote:
>
>> I'm working on fixing PR21471, which is about embedding codegen command
>> line options into the bitcode as function or module-level attributes so
>> that they don't get ignored when doing LTO.
>>
>> http://llvm.org/bugs/show_bug.cgi?id=21471
>>
>> I have an initial patch (attached to this email) which enables clang/llvm
>> to recognize one command line option, write it to the IR, and read it out
>> in a backend pass. I'm looking to get feedback from the community on
>> whether I'm headed in the right direction or whether there are alternate
>> ideas before I go all the way on fixing the PR.
>>
>
> Glad to see you working on it.
>
>
>> Specifically, I'd like to know the answers to the following questions:
>>
>> 1. How do we make sure we continue to be able to use the command line
>> options we've been using for llc and other tools?
>> 2. How to handle cases where two functions in a module have different
>> sets of command line options?
>> 3. Where should the command line options or module/function attributes be
>> stored once they are read out from the IR?
>>
>>
> Yes. These are some of the important questions. I think you're missing a
> few things to take into consideration:
>
> a) How does this change the pass manager? Some of the command line options
> (many) change which passes are run when. It should be as simple as checking
> the function attribute for each pass to decide when to run, but if one
> invokes a chain then you might have other issues or if the command line
> option invokes module/cgscc passes (see c below).
>
>
b) Right now I'm using a combination of stringified target-cpu and
> target-features with each target's cpu specific attributes (i.e. something
> like mips16) being a separate option that gets plugged into the subtarget -
> if it controls the creation of a subtarget. I don't know that any do (at
> least a quick glance didn't seem to say), but if a command line option
> controls any of the initialization in the subtarget dependent features
> it'll need to be part of the key to look up the subtarget. If it doesn't
> then you'll just need to check the attribute, as you said, in the
> pass/lowering/thingy.
>
>
Yes, I saw that code. I was thinking I would have to change the map's key
type to a tuple of strings and options, but perhaps there is a more
efficient way to do the look up.


> c) Which command line options need to be part of this interface? I don't
> necessarily think all of them should which could turn some of these into
> subtarget features that can just be added on to the functions as they go.
> If anything can't change between translation units then a module level flag
> that errors on merge would be applicable. I'd prefer not to use module
> level flags for things that can just be put on every function. The module
> level flags could be read into a subtarget specific global target options
> flag (ala soft-float).
>
>
Is there a way to attach a subtarget feature string to a function without
using AttributeSet? I'm not sure I understand why subtarget features are
preferable to function attributes.


> d) linkonce_odr functions with different attributes
>
> e) How to organize these so that it's easy for a particular target to know
> what attributes it might put on a function or module?
>
> Probably more :)
>
> Other possible ideas that I've discussed or thought about, but haven't
>> implemented:
>>
>> 1. Treat cl::opt options as overrides, possibly by setting a bit that
>> indicates the option has been specified in the command line.
>>
>> 2. Extend the idea proposed in the discussion on llvm-dev about removing
>> static initializer for command line options:
>>
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html
>>
>> I looked at the code that was checked in to trunk and it seems to me that
>> it isn't possible to have storage for command line options on a
>> per-function storage basis yet, which I think is necessary if the functions
>> in a module have different sets of command line options.
>>
>>
> I don't think either of these are a good idea.
>
> Thoughts?
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141114/9e26ab79/attachment.html>