[LLVMdev] The Trouble with Triples (original) (raw)

Eric Christopher echristo at gmail.com
Wed Jul 29 16:55:10 PDT 2015

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

More information about the llvm-dev mailing list