<div dir="ltr"><div>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.</div><div><br></div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=21471">http://llvm.org/bugs/show_bug.cgi?id=21471</a></div><div><br></div><div>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:</div><div><br></div><div>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?</div><div>2. How to handle cases where two functions in a module have different sets of command line options?</div><div>3. Where should the command line options or module/function attributes be stored once they are read out from the IR?</div><div><br></div><div>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.</div><div><br></div><div>Other possible ideas that I've discussed or thought about, but haven't implemented:</div><div><br></div><div>1. Treat cl::opt options as overrides, possibly by setting a bit that indicates the option has been specified in the command line.</div><div><br></div><div>2. Extend the idea proposed in the discussion on llvm-dev about removing static initializer for command line options:</div><div><br></div><div><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html</a></div><div><br></div><div>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.</div></div>