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. 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. If you think this change should not happen, or should happen differently, please let me know. Nick
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. 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? -Chris
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. Nick