search for: deglob

Chris Lattner wrote: > On Dec 1, 2011, at 5:23 PM, Nick Lewycky wrote: >>> 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

On Dec 1, 2011, at 5:23 PM, Nick Lewycky wrote: >> 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

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

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

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