[LLVMdev] The Trouble with Triples

[Eric Christopher]

>
> 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 undesirable, especially in the IR.
>
>
Yes.


> 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.
>
>
Definitely don't want this in the middle end at all. That all can be part
of the TargetMachine/TargetSubtargetInfo interface.


> 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.
>
>
This part I agree with.


> The decision to create a new class (Tuple) is because Triple already
> has a legacy-heavy meaning, which should not change.
>
>
Agreed with at least the "because" part.


> 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. :)
>
>
OK. What's the general class design look like then? The text from the
original mail was fairly confusing then as I thought he was doing something
that you say he isn't doing :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/65e9019b/attachment.html>