search for: triples

...nt this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was uncertain... I'm not sure if they'd prefer to use 'none' or rather just omit that part of the triple. So on those, I've left them to use Triple::UnknownOS. Cheers, Jon On 6/17/14, 11:11 AM, Eric Christopher wrote: > Agreed. > > -eric >...

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

...nathan Roelofs <jonathan at codesourcery.com> wrote: >>>> Attached is what I now think the patch ought to be. >>> >>> Does unknownOS *always* mean bare-metal? >> I'm not sure. It might be a good time to fork this thread, and start another >> about triples for bare-metal... > > Personally, I think we ought to add a 'None' entry to the OSType enum > specifically for baremetal, and then map triples like arm-none-eabi and > arm--eabi to it (but not arm-foobar-eabi, for example). > > Thoughts? > > Jon > >>> &gt...

...u know, LLVM uses a GNU Triple is as a target description that can be relied upon to make decisions. It's used for various decisions such as the default cpu, the alignment of types, the object format, the names for libcalls, and a wide variety of others. In using it like this, LLVM assumes that triples are unambiguous and have a specific defined meaning. Unfortunately, this assumption fails for a number of reasons. The first reason is that compiler options can overrule the triple but leave it unchanged. For example, in GCC mips-linux-gnu-gcc normally produces 32-bit MIPS-I output using the O32 A...

...riple is as a target description that can be > relied upon to make decisions. It's used for various decisions such as the > default cpu, the alignment of types, the object format, the names for > libcalls, and a wide variety of others. > > In using it like this, LLVM assumes that triples are unambiguous and have > a specific defined meaning. Unfortunately, this assumption fails for a > number of reasons. > > > > The first reason is that compiler options can overrule the triple but > leave it unchanged. For example, in GCC mips-linux-gnu-gcc normally > produc...

...tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used by Debian for our N64 port. Once the ABI is in our backend triples, it can be used by MipsMCAsmInfo to enable IAS by default for N64 without also enabling it for N32. In later patches, such as D1292 this same information will also be used to fix the N32 support for IAS. At this point, you may be wondering what happens to Triple::GNU for triples like mips-linux-gn...

...efinedRefs() depends on the ABI but IRObjectFile doesn't know it. How would you deliver the ABI to IRObjectFile? The second problem is that IRLinker will link incompatible IR together because it doesn't know the ABI's involved in the link. It thinks it's sufficient to check that the triples are the same. How would you prevent it from linking IR intended for O32 with IR intended for N64? I'm also worried about the risk of undiscovered problems on the pass-MCTargetOptions-everywhere path but it's difficult to discuss those for obvious reasons. However, I think it's safe to...

...u've written 'triple'. I'm answering based on the assumption you meant 'triple') The GNU triple is already used as a way of encoding a large amount of the target data in a string but unfortunately, while this data is passed throughout LLVM, it isn't reliable because GNU triples are ambiguous and inconsistent. For example, in GCC toolchains mips-linux-gnu probably means a MIPS target on Gnu/Linux but anything beyond that (ISA revision, default ABI, multilib layout, etc.) is up to the person who built the toolchain and may change over time. Another example is that Debian...

Eric Christopher wrote: > On Wed, Jul 9, 2014 at 11:39 AM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> On 7/9/14, 12:33 PM, Eric Christopher wrote: >>> Any reason why you deleted code that isn't related? >>> >>> -eric >>> >>>> - enum SubArchType { >>>> - NoSubArch, >>>> -

Hi all. I’ve been working with Swift on ARMv6 and v7. While working with ARMv6 on linux, I noticed that my arm architecture canonicalization code didn’t produce the expected result. The code that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); //

...iple-related information that is implied by the triple but isn't textually present such as the default CPU that clang should use. The separation provides a good point to account for configure-time/run-time triple customization. Additionally, Renato wants this separation because interpreting ARM triples is hard and he needs somewhere to store the interpreted meaning. Similarly, the backend also believes that Triple::mips implies O32 and Triple::mips64 implies N64 (N32 isn't represented) but we already have a plan to sort that out. > Sounds like it was a bug that was fixed. :) That's p...

...g based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout LLVM, it isn't reliable because GNU triples are ambiguous and > inconsistent. For example, in GCC toolchains mips-linux-gnu probably means > a MIPS target on Gnu/Linux but anything beyond that (ISA revision, default > ABI, multilib layout, etc.) is up to the person who built the toolchain and > may change over time. Another examp...

...small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. > > > > So here’s what I would suggest. > > > > 1. Define the target triple as follows (adapted from Triple.h): > > > > /// Target triples are strings in the canonical form: > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM > > /// or > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT > > /// or > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT > > /// or > > /// ARCHI...

> > (from the context, you might have meant 'tuple' where you've written 'triple'. I'm answering based on the assumption you meant 'triple') > I did mean what I wrote. I thought I ought to check since it's very easy to mix up triples and tuples and the context sounded off. I'm glad I picked the right assumption. > > The proposed TargetTuple is a direct replacement for the GNU triple and is intended to resolve this ambiguity and move away from a > > string-based implementation (we need to keep a string serializa...

...GCC toolchain since I only found out when a user asked about it. ________________________________ From: Eric Christopher [echristo at gmail.com] Sent: 23 September 2015 23:23 To: Daniel Sanders; Renato Golin; Jim Grosbach Cc: llvm-dev at lists.llvm.org; Matthew Fortune Subject: Re: The Trouble with Triples On Wed, Sep 23, 2015 at 3:00 PM Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote: > > Note that the same problems exist and that they are unrelated to the existence > > of TargetMachine or not since TargetMachine gets the relevant i...

...at’s much of a problem. Given that object format is a relatively small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. So here’s what I would suggest. 1. Define the target triple as follows (adapted from Triple.h): /// Target triples are strings in the canonical form: /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT-ENVIRONMENT 2....

...nce) and also propose my plans on how to support the ARM platform better, especially cross-compilation in Clang. All this discussion came as a spin-off of bug 8911 (http://llvm.org/bugs/show_bug.cgi?id=8957)... Today we have three major problems in cross-compiling to ARM with Clang: 1. Some ARM triples "arm*-none-eabi" don't get properly recognized, so Clang doesn't generate correct AAPCS (soft and hard) calls and don't pass the correct triple to LLC. 2. Some options in Clang are chosen by parsing the triple directly, because triples don't have all properties necessary...

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

...at’s much of a problem. Given that object format is a relatively small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. So here’s what I would suggest. 1. Define the target triple as follows (adapted from Triple.h): /// Target triples are strings in the canonical form: /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT-ENVIRONMENT 2....

...there. I have some questions on that but I'll reply there. ________________________________ From: Eric Christopher [echristo at gmail.com] Sent: 23 September 2015 22:28 To: Daniel Sanders; Renato Golin; Jim Grosbach Cc: llvm-dev at lists.llvm.org; Matthew Fortune Subject: Re: The Trouble with Triples On Wed, Sep 23, 2015 at 2:19 PM Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote: Rewrote the ABI example in terms of clang -cc1as which is a supported tool. Which is still just calling the same set of APIs I mentioned in my previous email so...