(original) (raw)

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

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.

\>> 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. :)

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.

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.

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