<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Definitely don't want this in the middle end at all. That all can be part of<br>
> the TargetMachine/TargetSubtargetInfo interface.<br>
<br>
Ah, yes! But the TargetMachine (& pals) are created from information<br>
from the Triple and the other bits that front-ends keep for<br>
themselves.<br>
<br></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, in theory, if the Tuple is universal, creating them with a Tuple<br>
(instead of a Triple+stuff) will free the front-ends of keeping the<br>
rest of the info on their own, and TargetMachine/SubTargetInfo/etc<br>
will be more homogeneous across different tools / front-ends than it<br>
is today.<br>
<br>
Another strong point is: we're not trying to change any other machine<br>
description / API. This is just about the user options and defaults,<br>
that are used to *create* machine descriptions.<br>
<br></blockquote><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> The decision to create a new class (Tuple) is because Triple already<br>
>> has a legacy-heavy meaning, which should not change.<br>
><br>
> Agreed with at least the "because" part.<br>
<br>
There was also the name. Triple is very far from the truth. :)<br>
<br></blockquote><div><br></div><div>Oh I don't know. It's a triple :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But changing the Triple class could cause ripples in the mud that<br>
would be hard to see at first, and hard to change later, after people<br>
started relying on it.<br>
<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The final goal is that the Triple class would end up as being nothing<br>
more than a Triple *parser*, with the current legacy logic, setting up<br>
the Tuple fields and using them to select the rest of the default<br>
fields.<br>
<br></blockquote><div><br></div><div>Hrm.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> OK. What's the general class design look like then? The text from the<br>
> original mail was fairly confusing then as I thought he was doing something<br>
> that you say he isn't doing :)<br>
<br>
Daniel, can you send your current plan for the Tuple class?<br><br></blockquote><div><br></div><div>Please. I don't think we're far off in goals, just perhaps implementation :)</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric </div></div></div>