search for: triple

...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 &gt...

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 write an LLVM backend for the cor...

...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 > >>> &g...

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 upon to make decisions. It's...

Hi Daniel, I'm not sure I agree with the basic idea of using the target triple as a way of encoding all of the pieces of target data as a string. I think in a number of cases what we need to do is either open up API to the back end to specify things, or encode the information into the IR when it's different from the generic triple. Ideally the triple will have enough info...

...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 also in a good state but the current N32 ABI support for IAS is badly broken and will likely take considerable effort to fix (and fixing it also requires solving the same key problem as enabling IAS for just N64...

...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...

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple. > Ideally the triple w...

...Here's one I've just generated against the latest svn. The TOT sources build fine with these additions. Is there any reason now why this patch cannot be submitted on my behalf? My concern is that I cannot submit further work for our chips to lldb until I have these definitions in llvm::Triple. I'll also repost this patch to llvm-commits. Thanks for your time and patience, Matt Index: include/llvm/ADT/Triple.h =================================================================== --- include/llvm/ADT/Triple.h (revision 212686) +++ include/llvm/ADT/Triple.h (working copy) @@ -...

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); // Canonicalization of all armv6 sub architectures to armv6 if (triple.getArch() == llvm::Triple::ArchType::arm) { if (triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArc...

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > > If it's something that's overridden later because it can't be represented by a triple then that &g...

Hi Daniel, > (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. > 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'...

...ndrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. > > > > I couldn’t find an explanation anywhere of w...

> > (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...

> > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > If it's something that's overridden later because it can't be represented by a triple then that > default need...

...drew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. I couldn’t find an explanation anywhere of what is meant by environ...

Hi all, There's been some controversies in the TargetTriple changes and I want to explain it better in the list (to a wider audience) 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 thr...

> > 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...

Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. I couldn’t find an explanation anywhere of what is meant by environ...

> > Note that the same problems exist and that they are unrelated to the existence > > of TargetMachine or not since TargetMachine gets the relevant information from > > the Triple it holds. This information is incorrect, even as a starting point. > > I believe we're going to disagree here as the TargetMachine does not get all of its > information from the Triple - except where the Triple is the canonical place for that > information and it isn't overridd...