search for: tripled

Eric, Attached are patches for llvm and clang that implement 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

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

[+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

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

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 information to do

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

Hi Eric, It's the unsolved problems on the pass-MCTargetOptions-everywhere path that are my main concern with that approach rather than the amount of work. The first problem is that the result of IRObjectFile::CollectAsmUndefinedRefs() 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

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.

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); //

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

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

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <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”.

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

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

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent:

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 three major problems in cross-compiling

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

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

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