search for: targetabi

.... Here's what I've gathered so far alongside with some questions. - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. - The CodeGenerator documentation claims that the AIX PowerPC ABI is followed (with some deviations). Is this refering to the DarwinABI? - In a recent commit a TargetABI value and enumeration was added to PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to either ELF-variant in resetSubtargetFeatures(...) based on endianess (unless explicitly set previously). As I understand it ELFv2 is a...

...arget.h there's DarwinABI, SVR4ABI and ELFv2ABI. > > - The CodeGenerator documentation claims that the AIX PowerPC ABI > > is > > followed (with some deviations). Is this refering to the DarwinABI? > > No, that's the ELFv1 ABI. > > > - In a recent commit a TargetABI value and enumeration was added to > > PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and > > PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to > > either ELF-variant in resetSubtargetFeatures(...) based on > > endianess > > (unless explici...

...> the triples (tablegen?). > > Another option that would make *all* distributions happy would be to > adopt the same approach as GCC and have CMake options for default ABI > choices. > > This would be harder to implement, but we can hide the mess under a > separate class (TargetABI?). I actually prefer this solution to either > tablegen or patch-sets. I can see a way to make the CMake option approach work nicely for native. The constructor can check for the default triple and apply the effects of the CMake options to it. I don't think there's a good way to support...

...; CM, CodeGenOpt::Level OL, bool isLittle) : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), TT, CPU, FS, Options, getEffectiveRelocModel(TT, RM), getEffectiveCodeModel(CM), OL), TargetABI(computeTargetABI(TT, CPU, Options)), TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) { ... } It does not create a separate Subtarget, and its getSubtargetImpl() tries to get the value from SubtargetMap. Is there any downside to keep BPFTargetMachine as is? Or it is worthwhile to impl...

...> No, that's the ELFv1 ABI. > But it describes both 64-bit and 32-bit linkage areas. Doesn't that imply that it isn't ELFv1? Just to be clear the document I'm talking about is: http://llvm.org/docs/CodeGenerator.html#llvm-powerpc-abi - David >> - In a recent commit a TargetABI value and enumeration was added to >> PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and >> PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to >> either ELF-variant in resetSubtargetFeatures(...) based on endianess >> (unless explicitly set previo...

...et/ARM/ARMSubtarget.cpp (working copy) @@ -264,7 +264,7 @@ default: if ((isTargetIOS() && isMClass()) || (TargetTriple.isOSBinFormatMachO() && - TargetTriple.getOS() == Triple::UnknownOS)) + TargetTriple.getOS() == Triple::NoneOS)) TargetABI = ARM_ABI_AAPCS; else TargetABI = ARM_ABI_APCS; Index: unittests/ADT/TripleTest.cpp =================================================================== --- unittests/ADT/TripleTest.cpp (revision 211122) +++ unittests/ADT/TripleTest.cpp (working copy) @@ -123,12 +123,6 @@ EXPECT_E...

...'clang -target x86_64-linux-android'? > Some people have suggested config files. So we'd have (say) > Targets.cfg on LLVM's source tree copied to the build tree, unless you > specify -DTARGETS_CONFIG=/foo/bar/UbuntuTargets.cfg, and that would > populate the defaults in TargetABI. Of course, this would be a big > change and it's probably for after we do all we already planned to. :) Some of my colleagues from other projects have suggested the same thing off-list. It sounds like a good solution to me. I haven't given much thought to the details yet, but the one c...

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

...enOpt::Level OL, bool >> isLittle) >> : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), >> TT, >> CPU, FS, Options, getEffectiveRelocModel(TT, RM), >> getEffectiveCodeModel(CM), OL), >> TargetABI(computeTargetABI(TT, CPU, Options)), >> TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) { >> ... >> } >> It does not create a separate Subtarget, and its getSubtargetImpl() tries to >> get the value >> from SubtargetMap. >> >> Is there a...

Hi, In http://reviews.llvm.org/D10969, Eric asked me to explain the wider context of the TargetTuple object that was replacing Triple on llvmdev so here it is. Before I start, I'm sure I don't know the full extent of GNU triple ambiguity and lack of canonicity. Additional examples are welcome. The Problem As you know, LLVM uses a GNU Triple is as a target description that can be relied