search for: r145714

...think that'll be cleanest overall. > > I'd really prefer these to be in a separate class: TM is just too huge and full of random things already. I'm not concerned about the actual sizeof(TargetMachine), so reusing a few bits in it shouldn't matter. Sounds good, committed in r145714 and a number of followup patches for the frontends. Unfortunately there's two failing buildbots left, both building llvm-gcc on ARM: http://lab.llvm.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float/ http://lab.llvm.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-...

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 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