search for: x86mctargetdesc

>> + bool HasAVX2 = HasAVX && !GetX86CpuIDAndInfo(0x7, &EAX, &EBX, &ECX, &EDX) && >> + (EBX & 0x20); > > I don't think this guarantees %ecx is 0, does it? Wasn't that the > entire reason the original code went wrong? I don’t remember really, but presuming the conclusions of the discussion, seems it is fixed now. It

..., seems it is fixed now. It was something about registers when using inline assembly. Anyway this works just fine on all my Haswell machines. I think that's more coincidence than anything else (something perturbed in your host compiler's backend). If you look at lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp there's a GetCpuIDAndInfoEx function which specifically sets %ecx to a valid value before executing "cpuid". The code in Host.cpp needs to do something similar. Cheers. Tim.

...b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp:100 #3 0x9cf3e1 in createX86MCAsmInfo(llvm::MCRegisterInfo const&, llvm::Triple const&) /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp:179:15 #4 0x421020 in createMCAsmInfo /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/Support/TargetRegistry.h:298:12 #5 0x421020 in Context /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/unittests/MC/DwarfLineTables.cpp:41 #6 0x4210...

...Static, our program should work on all platforms except Darwin: // If we are on Darwin, disallow static relocation model in X86-64 mode, since // the Mach-O file format doesn't support it. if (RM == Reloc::Static && TT.isOSDarwin() && is64Bit) RM = Reloc::PIC_; (from X86MCTargetDesc.cpp) First, is the Mach-O limitation still there? Second, is it okay to silently fold into Reloc::PIC_ in this case and leave the user with sporadic crashes? Finally, can we bypass this limitation by simply appending "-elf" to our Target Triple, forcing ELF generation on all three platfo...

...as something about registers when > using inline assembly. Anyway this works just fine on all my Haswell > machines. > > I think that's more coincidence than anything else (something > perturbed in your host compiler's backend). If you look at > lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp there's a > GetCpuIDAndInfoEx function which specifically sets %ecx to a valid > value before executing "cpuid". > > The code in Host.cpp needs to do something similar. > > Cheers. > > Tim. > > _______________________________________________ > LLVM...

...:TargetSpec class" (http://nondot.org/sabre/LLVMNotes/TargetSpec.txt) seems to address this, although AFAICS the current llvm::Triple does not explicitly specify the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTargetDesc.cpp: --------------- static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Ctx, MCAsmBackend &MAB, raw_ostream &_OS, MCCodeEmitter *_Emitter,...

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

...:TargetSpec class" (http://nondot.org/sabre/LLVMNotes/TargetSpec.txt) seems to address this, although AFAICS the current llvm::Triple does not explicitly specify the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTargetDesc.cpp: --------------- static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Ctx, MCAsmBackend &MAB, raw_ostream &_OS, MCCodeEmitter *_Emitter,...

...platforms except Darwin: > > // If we are on Darwin, disallow static relocation model in X86-64 mode, > since > // the Mach-O file format doesn't support it. > if (RM == Reloc::Static && TT.isOSDarwin() && is64Bit) > RM = Reloc::PIC_; > > (from X86MCTargetDesc.cpp) > > First, is the Mach-O limitation still there? Yes, the Mach-O limitation still exists as far as I know. Second, is it okay to > silently fold into Reloc::PIC_ in this case and leave the user with > sporadic crashes? Large code model and PIC should be compatible. Finally, c...

...63, 69 & 70 model, following changes in Linux kernel & Xen. Also set 62 as Ivy Bridge EP aka E5 v3 (which I has in my workstation). Cheers, -- Adam Detects x86 family 6 model 60, 63, 69, 70 CPU that has AVX2 CPUID leaf 7 subleaf 0 AVX2 flag as core-avx2. Port GetX86CpuIDAndInfoEx from X86MCTargetDesc to support x86 CPUID subleafs. Also detect family 6 model 62 (0x3E) Ivy Bridge EP as core-avx-i. --- lib/Support/Host.cpp | 96 ++++++++++++++++++++++++++++++++++++++--- lib/Target/X86/X86Subtarget.cpp | 7 ++- 2 files changed, 96 insertions(+), 7 deletions(-) diff --git a/lib/Suppor...

...X86/InstPrinter/Release+Asserts/X86IntelInstPrinter.o differ: byte 107220, line 484 ./lib/Target/X86/AsmParser/Release+Asserts/X86AsmParser.o ../../recurse2be/build/./lib/Target/X86/AsmParser/Release+Asserts/X86AsmParser.o differ: byte 287278, line 1617 ./lib/Target/X86/MCTargetDesc/Release+Asserts/X86MCTargetDesc.o ../../recurse2be/build/./lib/Target/X86/MCTargetDesc/Release+Asserts/X86MCTargetDesc.o differ: byte 159231, line 159 ./lib/Target/Sparc/Release+Asserts/SparcISelDAGToDAG.o ../../recurse2be/build/./lib/Target/Sparc/Release+Asserts/SparcISelDAGToDAG.o differ: byte 25814, line 106 ./lib/Target/Sparc...

...Order.cpp for Release+Asserts build llvm[3]: Compiling ExternalFunctions.cpp for Release+Asserts build llvm[4]: Compiling X86MCCodeEmitter.cpp for Release+Asserts build llvm[3]: Compiling SROA.cpp for Release+Asserts build llvm[2]: Compiling Analysis.cpp for Release+Asserts build llvm[4]: Compiling X86MCTargetDesc.cpp for Release+Asserts build llvm[3]: Compiling Interpreter.cpp for Release+Asserts build llvm[2]: Compiling AtomicExpandPass.cpp for Release+Asserts build llvm[3]: Building Release+Asserts Archive Library libLLVMInterpreter.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Exe...