search for: targettuple

...them. · But we can't keep using Triples inappropriately either. If the information feeding into LLVM is faulty then the resulting behaviour will be faulty too. · So let's start with a Triple, and convert it to a not-broken equivalent as early as possible. We'll call it TargetTuple. Are there any disagreements on this part of the thinking? If there are, then we should resolve these before proceeding to the rest since everything else depends on accepting this core problem exists and can be fixed in this way. If we have agreement on this, then I think that this by itself is amp...

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

...ly help with this effort if you need assistance or guidance in any way. Thanks! -eric On Wed, Jul 8, 2015 at 7:31 AM Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > 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,...

On 9 July 2015 at 10:39, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > TM.createX(llvm::TargetTuple(llvm::Triple(TripleStr)), ...) Could you have a constructor for TargetTuple(string) to build a triple on its own? --renato

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

...PS 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's definition for i386-linux-gnu has been i486 and i586 at various points in time. 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 serialization though, see below). Essentially, I'm trying to push the ambiguity out of the internals and give the distributor control o...

...us email, this is about clearing the bloat in target descriptions by both: removing the need for adding numerous CPU names, target features, architecture names (xscale, strongarm, etc), AND making sure all parties (front/middle/back-ends) speak the same language, produced from the same source. The TargetTuple is that common language, and the TargetParser created from the TableGen files is the common source. The Triple becomes a legacy constructor value for the Tuple. All other target information classes are already (or should be) generated from the TableGen files, so the ultimate source becomes the Tabl...

...It should also be noted that the -EL and -EB options currently operate by hacking the triple and replacing the first component. >e) The rest of the "countless details" may or may not be relevant, you haven't > given an example of what you care about. "grep 'TT\.\|TheTargetTuple\.'" reveals most of the details that LLVM's various targets derive from the triple. I don't understand all the decisions being made by all targets but they are definitely using information from the triple to make behavioural decisions throughout the backends. > From here on you...

...nd 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's definition for > i386-linux-gnu has been i486 and i586 at various points in time. > > Sorta... > 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 serialization though, see below). > Essentially, I'm trying to push the ambiguity out of the internals and give > the d...

...en '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 serialization though, see below). Essentially, I'm trying to push the ambiguity > > out of the internals and give the d...

...ere on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions. At this point, in the MC layer we have a number of classes that need to know the ABI but lack this information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don...

> Another very annoying fact is that the Clang driver re-parses triples many > times, and sometimes they change the triple based on a CPU, and then end > up with a different CPU. I’ve recently been tasked with cleaning this up. Before starting on this full gusto, I want to make sure I’m not stepping on any toes or duplicating work. The rough plan is as follows; 1. Replace the call to

...iel Sanders <Daniel.Sanders at imgtec.com> wrote: > After re-reading your last couple emails with the benefit of sleep, that all makes sense to me. The user/driver would be responsible for ensuring each tool is called with the same options, while each tool is responsible for using the same TargetTuple in all its calls to LLVM. The only bit I'm unsure about w.r.t to not having a serialization in the IR is the ModuleLinker where we currently have code to ensure that all the modules are compatible (by comparing the triple). Presumably, this code was added because there was a real possibility of...

...ere on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions. At this point, in the MC layer we have a number of classes that need to know the ABI but lack this information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don...

...ere on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions. At this point, in the MC layer we have a number of classes that need to know the ABI but lack this information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don...

...apsulate that data directly. > Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent > - see TargetSubtargetInfo/MCSubtargetInfo) should encapsulate everything that's needed > from the object level down for any particular target. That sounds like TargetTuple but spelt something like MCTargetMachine. It sounds like MCTargetMachine should usurp the Triple in the places it exists in the MC layer (and maybe be introduced to a few new portions of it) and accurately reflect the desired target just like in the later stages of the TargetTuple plan intended. Th...

...ere on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions. At this point, in the MC layer we have a number of classes that need to know the ABI but lack this information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don...

...ere on your email relies on all of these assumptions being true. So I'm going to skip past that part and go to where you answer some of my questions. At this point, in the MC layer we have a number of classes that need to know the ABI but lack this information. Our TargetMachine has an accurate TargetTuple object that describes the invariants of the desired target. The desired ABI is an invariant too so why not have it in the TargetTuple which is already plumbed in everywhere we need it? After all, it's a property of the target OS/Environment. If we have the ABI in the TargetTuple, then we don...

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

On 30 July 2015 at 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > We will need a string serialization of the TargetTuple so that we can store it in the IR and read it back. Why does it have to be in the IR? If every tool that deals with IR has the same options and they mean the same thing I don't see why we'd need that. > Whether this is in one piece (e.g. 'target tuple = "...") or multipl...