[LLVMdev] deglobalizing TargetOptions

Nick Lewycky nlewycky at google.com
Thu Dec 1 17:23:36 PST 2011

On 1 December 2011 17:15, Chris Lattner <clattner at apple.com> wrote:
> On Dec 1, 2011, at 5:09 PM, Nick Lewycky wrote:
>> I'm running LLVM under threadsanitizer
>> (http://code.google.com/p/data-race-test/) to find and remove races in
>> a larger program that uses LLVM as a library. One of the things that I
>> found is that the TargetOptions are all global; you could create a
>> TargetMachine targeting ARM and X86 in two threads, but they both have
>> to share the same FloatABIType setting.
>> This is silly, and I plan to fix it by moving all the globals in
>> TargetOptions into getters and setters on TargetMachine. This means
>> that the TargetMachine object is going to get a bit bigger to
>> accommodate, but at least two users of llvm linked into one program
>> won't step on each other.
> Sounds great.
>> The existing command-line options will move
>> from TargetMachine into llc which will use the same setters. This has
>> the side-effect that "clang -mllvm" won't work for them any more.
> Sounds fine.

Thanks Chris!

> Instead of adding a bunch of instance variables (+ getters/setters) into TargetMachine, why not make TargetOptions be a class, and have TM contain an instance of it?

That works too, it makes little difference to me. One reason is that
most references to these globals are inside classes that derive from
TargetMachine so I wouldn't need to touch those lines. The second
reason is that I'm going to turn "bool Foo" into "unsigned Foo : 1"
and would like that to pack in with the 6 variables that are currently
members of the TargetMachine.

How about I just move the 6 existing flags into TargetOptions and even
remove their getters/setters. I think that'll be cleanest overall.


More information about the llvm-dev mailing list