similar to: [LLVMdev] The Trouble with Triples

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

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

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

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

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

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

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

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

> 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

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

Daniel: Thanks for your detailed response. I had seen the discussion from earlier this year, but when I read it, I didn't expect it would be so difficult to get just one bit of information where I wanted it. :-) Thanks for the heads up about clang not necessarily setting ABIname. I have at least enough of that working already that I can generate the appropriate assembly source. After doing a

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

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

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

> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: 08 July 2015 16:09 > To: Daniel Sanders > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Eric Christopher > (echristo at gmail.com); Jim Grosbach (grosbach at apple.com) > Subject: Re: The Trouble with Triples > > On 8 July 2015 at 15:31, Daniel Sanders

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.

On 30 July 2015 at 15:30, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I haven't fully researched why the triple is there but one reason is to make backends target the same target as the frontends. Consider the case where clang is used to generate IR and then llc is used to compile it. We currently use the information in the IR to set the GNU triple, the target features,

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

On 31 July 2015 at 17:47, Daniel 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