[LLVMdev] The Trouble with Triples

[Eric Christopher]

>
>
> > Definitely don't want this in the middle end at all. That all can be
> part of
> > the TargetMachine/TargetSubtargetInfo interface.
>
> Ah, yes! But the TargetMachine (& pals) are created from information
> from the Triple and the other bits that front-ends keep for
> themselves.
>
>
Yep.


> So, in theory, if the Tuple is universal, creating them with a Tuple
> (instead of a Triple+stuff) will free the front-ends of keeping the
> rest of the info on their own, and TargetMachine/SubTargetInfo/etc
> will be more homogeneous across different tools / front-ends than it
> is today.
>
> Another strong point is: we're not trying to change any other machine
> description / API. This is just about the user options and defaults,
> that are used to *create* machine descriptions.
>
>
Agreed. This sounds like the direction I've been wanting to go for a bit
with some target options being passed along at target machine creation time
etc. It's hard though :)


>
> >> 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.
>
> There was also the name. Triple is very far from the truth. :)
>
>
Oh I don't know. It's a triple :)


> But changing the Triple class could cause ripples in the mud that
> would be hard to see at first, and hard to change later, after people
> started relying on it.
>
>
Agreed.


> The final goal is that the Triple class would end up as being nothing
> more than a Triple *parser*, with the current legacy logic, setting up
> the Tuple fields and using them to select the rest of the default
> fields.
>
>
Hrm.


>
> > 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 :)
>
> Daniel, can you send your current plan for the Tuple class?
>
>
Please. I don't think we're far off in goals, just perhaps implementation :)

Thanks!

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