similar to: [LLVMdev] The Trouble with Triples

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

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

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

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

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.

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

> On Jul 31, 2015, at 10:56 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On 30 July 2015 at 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com <mailto: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

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

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

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

> There will be no string representation of all options, as that would > be impossible, or at least, highly undesirable, especially in the IR. I just want to double check we're saying the same thing here. We will need a string serialization of the TargetTuple so that we can store it in the IR and read it back. Whether this is in one piece (e.g. 'target tuple = "...") or

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

On Fri, Jul 31, 2015 at 12:22 PM Owen Anderson <resistor at mac.com> wrote: > > On Jul 31, 2015, at 11:28 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Jul 31, 2015, at 10:56 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On 30 July 2015 at 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com> >> wrote: >> > We

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 Jul 31, 2015, at 11:28 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jul 31, 2015, at 10:56 AM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >> >> >> On 30 July 2015 at 14:52, Daniel Sanders <Daniel.Sanders at imgtec.com <mailto:Daniel.Sanders at imgtec.com>> wrote: >>

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.

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,

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

On 29 July 2015 at 21:44, Eric Christopher <echristo at gmail.com> wrote: > 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. Hi Eric, That's not the idea at all. The Triple object will remain unchanged. The Tuple will be the API to handle getting/setting parameters depending on the