<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The Triple object will remain unchanged.<br>
<br>
The Tuple will be the API to handle getting/setting parameters<br>
depending on the Triple, compiler flags, attributes, etc.<br>
<br></blockquote><div><br></div><div>This part doesn't seem obvious from the direction the patches are going. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There will be no string representation of all options, as that would<br>
be impossible, or at least, highly undesirable, especially in the IR.<br>
<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Tuple is for the sole use of front-ends, middle-ends and back-ends<br>
to communicate and understand the *same* meaning regarding the *same*<br>
input.<br>
<br></blockquote><div><br></div><div>Definitely don't want this in the middle end at all. That all can be part of the TargetMachine/TargetSubtargetInfo interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having a Tuple class that encodes details of the targets go a long way<br>
to ensure that, since you can directly pass the Tuple when you build<br>
the Target objects, and the information it provides will be identical,<br>
no matter where it is. Right now, we have multiple representations of<br>
the targets' information because the Triple object cannot encode every<br>
aspect of them, especially problematic between Clang and LLVM.<br>
<br></blockquote><div><br></div><div>This part I agree with.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The decision to create a new class (Tuple) is because Triple already<br>
has a legacy-heavy meaning, which should not change.<br>
<br></blockquote><div><br></div><div>Agreed with at least the "because" part.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is not about the serialization of the target information, but<br>
rather the consistent manipulation of it inside the compiler.<br>
<br>
<br>
> My suggestion on a route forward here is that we should look at the<br>
> particular API and areas of the backend that you're having an issue with and<br>
> figure out how to best communicate the data you'd like to the appropriate<br>
> area.<br>
<br>
That is precisely what he's doing. :)<br><br></blockquote><div><br></div><div>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 :)</div><div><br></div><div>-eric </div></div></div>