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

[Eric Christopher]

On Mon Nov 17 2014 at 9:56:40 AM Bob Wilson <bob.wilson at apple.com> wrote:

>
> > On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> >
> > +chrisb
> >
> >> On 2014-Nov-13, at 16:33, 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. 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?
> >>
> >> The short description of the approach I took in my patch is that
> command line options that are important to codegen are collected by
> cl::ParseCommandLineOptions, written to the bitcode as function or module
> attributes, and read out directly by the optimization passes that need
> them. cl::opt options are replaced with CodeGenOpt options (subclass of
> cl::opt), which are needed only to parse the command line and provide the
> default value when the corresponding options are not in the bitcode.
> >
> > I like this approach, since it means the frontend doesn't have to
> understand
> > options in order to pass them on to the backend.
>
> I agree. It’s not the approach that was I was expecting, but after reading
> the patches, I like it.
>
> If we can get consensus on the approach, I suggest that we stage the work
> to first adopt Akira’s patches and then we can incrementally convert
> various options over to use it. There may be complications for some
> options, so I’d like to see separate patches for each one (possibly with a
> few similar options combined in one patch).
>
>
I'm not sold quite yet :)

Akira: Can you show an example of how you expect this to work in the IR and
how the backend is going to process?

Thanks.

-eric


> >
> > The static variables should be straightforward to migrate to an
> LLVMContext
> > once ParseCommandLineOptions stores things there instead of in globals.
> >
> >> diff --git a/lib/CodeGen/CodeGenOption.cpp b/lib/CodeGen/CodeGenOption.
> cpp
> >> new file mode 100644
> >> index 0000000..2d74c2f
> >> --- /dev/null
> >> +++ b/lib/CodeGen/CodeGenOption.cpp
> >> @@ -0,0 +1,59 @@
> >> +//===- CodeGen/CodeGenOptions.cpp - Code-gen option.           --*-
> C++ -*-===//
> >> +//
> >> +//                     The LLVM Compiler Infrastructure
> >> +//
> >> +// This file is distributed under the University of Illinois Open
> Source
> >> +// License. See LICENSE.TXT for details.
> >> +//
> >> +//===------------------------------------------------------
> ----------------===//
> >> +//
> >> +//===------------------------------------------------------
> ----------------===//
> >> +
> >> +#include "llvm/CodeGen/CodeGenOption.h"
> >> +#include "llvm/IR/Attributes.h"
> >> +#include "llvm/IR/Module.h"
> >> +
> >> +using namespace llvm;
> >> +
> >> +static std::map<std::string, bool> FunctionBoolAttrs;
> >> +static std::map<std::string, bool> ModuleBoolAttrs;
> >> +
> >
> > @Chris, should these be using ManagedStatic?
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> 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/20141117/e79d3bd7/attachment.html>