llvm dev - Nov 2014 - [LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)

> On 2014-Nov-14, at 13:58, 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.
Unfortunately the pass manager isn't a safe place to hack right now.
> It should be as simple as checking the function attribute for each pass to
decide when to run,
Right, these are easy.
> but if one invokes a chain then you might have other issues
Just for clarity, if an option changes the passes from:

    -instcombine

to:

    -instcombine -some-pass1 -some-pass2 -instcombine

then ideally, we'd attach an attribute to the functions affected by
that option, and `-some-pass1 -some-pass2 -instcombine` would be
skipped for functions without that attribute.

IIUC, you're saying that skipping the second -instcombine is hard,
which I agree with.

Agreed.  I'm comfortable leaving that to be solved later, once the
new pass manager is in place.  Thoughts?
> 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.
> 
> 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.
Can you give an example of these?
> 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).
Agreed.
> d) linkonce_odr functions with different attributes
Doesn't this just get handled by lib/Linker?  I figure we keep the
attributes of the version of the function that "wins".
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

>
>
> > 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.
>
> Unfortunately the pass manager isn't a safe place to hack right now.
>
>
*shrug* Just hack it if necessary.

> > It should be as simple as checking the function attribute for each
pass
> to decide when to run,
>
> Right, these are easy.
>
Yep.

>
> > but if one invokes a chain then you might have other issues
>
> Just for clarity, if an option changes the passes from:
>
>     -instcombine
>
> to:
>
>     -instcombine -some-pass1 -some-pass2 -instcombine
>
> then ideally, we'd attach an attribute to the functions affected by
> that option, and `-some-pass1 -some-pass2 -instcombine` would be
> skipped for functions without that attribute.
>
> IIUC, you're saying that skipping the second -instcombine is hard,
> which I agree with.
>
> Agreed.  I'm comfortable leaving that to be solved later, once the
> new pass manager is in place.  Thoughts?
>
Agreed, I don't know of many of these anyhow outside of the atomic lowering.

>
> > 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.
> >
> > 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.
>
> Can you give an example of these?
>
-mips16 is the trivial example that already exists. -mabi= would probably
be another when you can change it per function.
(__attribute__((pcs("aapcs")))). Probably more, just those are the
ones
that come to mind.

>
> > 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).
>
> Agreed.
>
> > d) linkonce_odr functions with different attributes
>
> Doesn't this just get handled by lib/Linker?  I figure we keep the
> attributes of the version of the function that "wins".
>
>
Right. Which one wins? You'll get inconsistent results depending on
ordering. Of course, you'd get that without linking them, but we should do
some sort of checking ideally.

Not necessarily objecting to Akira's plan at the moment in case that was a
concern.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141114/9d5787e4/attachment.html>

> On 2014-Nov-14, at 15:07, Eric Christopher <echristo at gmail.com>
wrote:
> 
> 
> > d) linkonce_odr functions with different attributes
> 
> Doesn't this just get handled by lib/Linker?  I figure we keep the
> attributes of the version of the function that "wins".
> 
> 
> Right. Which one wins? You'll get inconsistent results depending on
ordering. Of course, you'd get that without linking them, but we should do
some sort of checking ideally.
You mean some lib/Linker tests, to make sure that the version of the
function that wins has its own attributes attached, instead of those
of one of the losing functions?  Yup, makes sense.