search for: x86_64targetmachin

...T).getArch()==Triple::x86_64' makes them *actually* identical. Can we just ditch the subclasses, move the fields and methods that they share into the X86TargetMachine class, and use that instead? Or am I missing something? In the patch I'm about to post to llvm-commits, I *stop* using the X86_64TargetMachine subclass entirely, and use X86_32TargetMachine for the 64-bit target. And the 16-bit target too. And nothing seems to have broken AFAICT... --- a/lib/Target/X86/X86TargetMachine.cpp +++ b/lib/Target/X86/X86TargetMachine.cpp @@ -24,8 +24,9 @@ using namespace llvm; extern "C" void LLVM...

On Mon, 2014-01-06 at 14:23 -0800, Jim Grosbach wrote: > Hi David, > > AFAIK, the answer is basically “because it’s always been that way.” I > seem to recall there were some things that were different (data layout > string and such), but that could also be parameterized if it hasn’t > been already by the recent refactorings, I suppose. It is *all* now parameterized. The classes

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

...world" application, found that the JIT compiler was not enabled. I'm completely new to LLVM, so I didn't know exactly where to look to see why the JIT for my platform wasn't being built (is it in the configure steps, or in the C++ code itself?). My educated guess is currently that X86_64TargetMachine::getJITMatchQuality is the interesting point. I have noticed that all the points in the codebase that try to detect x86-64 are currently using the gcc-style "__x86_64__" preprocessor symbol. The Visual Studio compiler, instead, defines _M_X64 (similar to the _M_IX86 define that matches...