search for: optionstor

...2. How to handle cases where two functions in a module have different sets of command line options? Today I don’t believe we have this ability. >> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? My suggestion would be the OptionStore that I proposed here: http://reviews.llvm.org/D6207 <http://reviews.llvm.org/D6207> >> >> 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...

...he second phase is to split the OptionRegistry into two pieces. The first piece is the parsing logic, and the second piece is the Option data store. The main goal of this phase is to make the OptionRegistry represent everything needed to parse command line options and to define a new second object, OptionStore, that is populated with values by parsing the command line. The OptionRegistry will be responsible for initializing “blank” option stores which can then be populated by either the command line parser, or API calls. The OptionRegistry should remain a singleton so that the parsing logic for all opt...

...onRegistry into two pieces. The first >> piece is the parsing logic, and the second piece is the Option data store. >> The main goal of this phase is to make the OptionRegistry represent >> everything needed to parse command line options and to define a new second >> object, OptionStore, that is populated with values by parsing the command >> line. The OptionRegistry will be responsible for initializing “blank” option >> stores which can then be populated by either the command line parser, or API >> calls. >> >> The OptionRegistry should remain a si...

...e something like "library link dependencies" where it is a list that we clearly just take the union to merge. > > >>> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? > > My suggestion would be the OptionStore that I proposed here: http://reviews.llvm.org/D6207 <http://reviews.llvm.org/D6207> > > Not to knock the option store (i quite like it), but I think that should be reserved for the cl::opt-style (but with your new API which is way better) debugging options, and never touch the IR. &gt...

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

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the