search for: createmcasminfo

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

...ossible to enable IAS by default for the N64 ABI without also > enabling it for the N32 ABI because this information is not reflected in the > triple and that's the only information MipsMCAsmInfo has. > > What would it take to pass more information to MipsMCAsmInfo? All callers of createMCAsmInfo() and LLVMCreateDisasmCPUFeatures() would need to specify the ABI. In the case of LLVMCreateDisasmCPUFeatures(), they'd move to a new variant of this function and some backward compatibility fixups would be left in the pre-existing version to maintain its current level of functionality where on...

On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in

Hi all. I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) { llvm::Target target = from_ruby<llvm::Target>(self); char const *triple = from_ruby<char const *>(tripleName); llvm::MCAsmInfo *MAI = target.createMCAsmInfo(triple); return to_ruby<llvm::MCAsmInfo>(*MAI); } The problem here, is it's ok...

...ast/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 0x421020 in __cxx_global_var_init /mnt/b/sanitizer-b...

...I move on to creating some of the needed ASM / REG info and an MCContext, etc.: std::unique_ptr<MCRegisterInfo> MRI(TheTarget->createMCRegInfo(TripleName)); assert(MRI && "Unable to create target register info!"); std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TripleName)); assert(MAI && "Unable to create target asm info!"); std::string MCPU("generic"); std::string FeaturesStr(""); MCObjectFileInfo MOFI; MCContext Ctx(MAI.get(), MRI.get(), &MOFI); MOFI.InitMCObjectFileInfo(TheTriple, llvm::Reloc...

...all. > > I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. > > To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: > > static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) > { > llvm::Target target = from_ruby<llvm::Target>(self); > char const *triple = from_ruby<char const *>(tripleName); > > llvm::MCAsmInfo *MAI = target.createMCAsmInfo(triple); > return to_ruby<llvm::MCAsmInfo>(*MA...

...ns a number of problems that need to be addressed and are completely unrelated to the MC layer. ABI Let's start at ExecuteAssembler() in cc1as_main.cpp. Here's a sketch of what happens: * Call TargetRegistry::lookupTarget() to get a llvm::Target. * Call createMCRegInfo(Triple, ...) * Call createMCAsmInfo(..., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInf...

...ns a number of problems that need to be addressed and are completely unrelated to the MC layer. ABI Let's start at ExecuteAssembler() in cc1as_main.cpp. Here's a sketch of what happens: * Call TargetRegistry::lookupTarget() to get a llvm::Target. * Call createMCRegInfo(Triple, ...) * Call createMCAsmInfo(..., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInf...

...ns a number of problems that need to be addressed and are completely unrelated to the MC layer. ABI Let's start at ExecuteAssembler() in cc1as_main.cpp. Here's a sketch of what happens: * Call TargetRegistry::lookupTarget() to get a llvm::Target. * Call createMCRegInfo(Triple, ...) * Call createMCAsmInfo(..., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInf...

...t return Triple::UnknownArch, the new arch this mutates the triple. Otherwise it applies the –march correctly but doesn't change the triple to match. In this way, it's possible to end up with i586-linux-gnu targeting the foobar architecture. · Call createMCRegInfo() · Call createMCAsmInfo() o MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::Priva...

...ns a number of problems that need to be addressed and are completely unrelated to the MC layer. ABI Let's start at ExecuteAssembler() in cc1as_main.cpp. Here's a sketch of what happens: * Call TargetRegistry::lookupTarget() to get a llvm::Target. * Call createMCRegInfo(Triple, ...) * Call createMCAsmInfo(..., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInf...

...t return Triple::UnknownArch, the new arch this mutates the triple. Otherwise it applies the –march correctly but doesn't change the triple to match. In this way, it's possible to end up with i586-linux-gnu targeting the foobar architecture. • Call createMCRegInfo() • Call createMCAsmInfo() o MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::Priva...

Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because

...ot; > +#include "AMDILFrameLowering.h" > +#include "AMDILIntrinsicInfo.h" > +#include "R600ISelLowering.h" > +#include "llvm/ADT/OwningPtr.h" > +#include "llvm/Target/TargetData.h" > + > +namespace llvm { > + > +MCAsmInfo* createMCAsmInfo(const Target &T, StringRef TT); > + > +class AMDGPUTargetMachine : public LLVMTargetMachine { > + > + AMDGPUSubtarget Subtarget; > + const TargetData DataLayout; > + AMDILFrameLowering FrameLowering; > + AMDILIntrinsicInfo IntrinsicInfo; > + const AMDGPUInstrInfo *...