[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> 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 multiple pieces (e.g. 'target arch = "..."', 'target endian = "..."') doesn't matter too much at first but I can see the benefits of the latter being the end point. If we do choose that multiple pieces then I'd like to pass through the former first to keep the early steps of the migration to a TargetTuple as simple and mechanical as possible. 

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 29 July 2015 23:44
> To: Eric Christopher
> Cc: Daniel Sanders; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Jim
> Grosbach (grosbach at apple.com)
> Subject: Re: The Trouble with Triples
> 
> 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 Triple, compiler flags, attributes, etc.
> 
> There will be no string representation of all options, as that would
> be impossible, or at least, highly undesirable, especially in the IR.
> 
> The Tuple is for the sole use of front-ends, middle-ends and back-ends
> to communicate and understand the *same* meaning regarding the *same*
> input.
> 
> Having a Tuple class that encodes details of the targets go a long way
> to ensure that, since you can directly pass the Tuple when you build
> the Target objects, and the information it provides will be identical,
> no matter where it is. Right now, we have multiple representations of
> the targets' information because the Triple object cannot encode every
> aspect of them, especially problematic between Clang and LLVM.
> 
> The decision to create a new class (Tuple) is because Triple already
> has a legacy-heavy meaning, which should not change.
> 
> This is not about the serialization of the target information, but
> rather the consistent manipulation of it inside the compiler.
> 
> 
> > My suggestion on a route forward here is that we should look at the
> > particular API and areas of the backend that you're having an issue with and
> > figure out how to best communicate the data you'd like to the appropriate
> > area.
> 
> That is precisely what he's doing. :)
> 
> cheers,
> --renato