search for: targettuples

I think we need to take a step further back and re-enter from the right starting point. The thing that's bothering me about the push back so far is that it's trying to discuss and understand the consequences of resolving the core problem while seemingly ignoring the core problem itself. The reason I've been steering everything back to GNU Triple's being ambiguous and inconsistent

...ng std::string's and StringRef's containing GNU triples with Triple objects. 2. Split the llvm::Triple class into llvm::Triple and llvm::TargetTuple classes. Both are identical in implementation and almost identical in interface at this stage. 3. Gradually replace Triples with TargetTuples until the C APIs and the LLVM-IR are the only place inside LLVM where Triples are still used. 4. Change the implementation of TargetTuple to whatever is convenient for LLVM's internals and decide on a serialization. 5. Replace serialized Triples with serialized TargetTuples in LLV...

...f's containing > GNU triples with Triple objects. > > 2. Split the llvm::Triple class into llvm::Triple and > llvm::TargetTuple classes. Both are identical in implementation and almost > identical in interface at this stage. > > 3. Gradually replace Triples with TargetTuples until the C APIs and > the LLVM-IR are the only place inside LLVM where Triples are still used. > > 4. Change the implementation of TargetTuple to whatever is > convenient for LLVM's internals and decide on a serialization. > > 5. Replace serialized Triples with se...

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

...ng std::string's and StringRef's containing GNU triples with Triple objects. 2. Split the llvm::Triple class into llvm::Triple and llvm::TargetTuple classes. Both are identical in implementation and almost identical in interface at this stage. 3. Gradually replace Triples with TargetTuples until the C APIs and the LLVM-IR are the only place inside LLVM where Triples are still used. 4. Change the implementation of TargetTuple to whatever is convenient for LLVM's internals and decide on a serialization. 5. Replace serialized Triples with serialized TargetTuples in LLV...

On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote: > Why do we care about GAS? We have an assembler. It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because

...f's containing > GNU triples with Triple objects. > > 2. Split the llvm::Triple class into llvm::Triple and > llvm::TargetTuple classes. Both are identical in implementation and almost > identical in interface at this stage. > > 3. Gradually replace Triples with TargetTuples until the C APIs and > the LLVM-IR are the only place inside LLVM where Triples are still used. > > 4. Change the implementation of TargetTuple to whatever is > convenient for LLVM's internals and decide on a serialization. > > 5. Replace serialized Triples with se...

...ng std::string's and StringRef's containing GNU triples with Triple objects. 2. Split the llvm::Triple class into llvm::Triple and llvm::TargetTuple classes. Both are identical in implementation and almost identical in interface at this stage. 3. Gradually replace Triples with TargetTuples until the C APIs and the LLVM-IR are the only place inside LLVM where Triples are still used. 4. Change the implementation of TargetTuple to whatever is convenient for LLVM's internals and decide on a serialization. 5. Replace serialized Triples with serialized TargetTuples in LLV...

> OK, I'm going to just reply to the last because I think it's the most important part of all this and would like to try to have us side tracked again. If you'd like I can reply to it, but let's take the last part first :) > > > > Could you please provide some examples of things that are impossible right now > > > with command lines, how those interact with

> 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

...patible (by comparing the triple). Presumably, this code was added because there was a real possibility of having incompatible modules (i.e. different triples) so we shouldn't rely on the tool options here. For this the serialization via metadata makes sense to me. We can then compare and merge TargetTuples with target-appropriate leniency and/or strictness. Exactly. That's why I suggested to not touch the triple and to add the rest as metadata. So that previous versions of Clang could still compile and link new IR and vice-versa. The triple still plays the part of the bare minimum in the new sc...

Eric Christopher echristo at gmail.com<mailto:echristo at gmail.com> writes: > The lack of a TargetMachine at the MC level was something I brought up a long time ago in this thread > with my proposed solutions. This is what needs to be fixed, especially given that targets can switch ISA, > ABI, floating point, etc within a single assemble action. I’ve been watching this thread in

Rewrote the ABI example in terms of clang -cc1as which is a supported tool. 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. Please do read the other examples in my previous email. It contains a number of

> > As I understand it your proposal aims to help solve the issue of getting the complete > > set of ABI information to every part of LLVM that needs it and you are saying > > TargetMachine should encapsulate that data directly. > Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent > - see TargetSubtargetInfo/MCSubtargetInfo) should

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

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

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.