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

Akira Hatanaka ahatanak at gmail.com
Thu Nov 13 16:33:05 PST 2014


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/32604258/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-pr21471.patch
Type: application/octet-stream
Size: 10379 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/32604258/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-pr21471.patch
Type: application/octet-stream
Size: 844 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/32604258/attachment-0001.obj>


More information about the llvm-dev mailing list