[LLVMdev] The Trouble with Triples

[Renato Golin]

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