<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote:</div></div><div>> This leads to a number of problems in LLVM:</div><div>> - we have a bunch of duplication</div><div>> - we have confusion about what a triple is (normalized or not)</div><div>> - no good way to tell if a triple is normalized</div><div>> - no good, centralized way to reason about which triples are allowed and valid</div><div>> - the MC assembler has to link in the entire X86 backend to get subtarget info</div><div>> - we don't have a good way to implement things like .code32 in the MC assembler</div><div>> - LLDB replicates a lot of this code and heuristics</div><div>> - we don't have good interfaces to inquire about the host</div><div>> - we do std::string manipulation in llvm::Triple</div><div>> - linux triples are actually quadruples!</div><div>> - darwin tools that take -arch have to map them onto something internally.</div><br class="Apple-interchange-newline">Most of these are motivations for refactoring and code cleanup, but not<div>really for inventing a new target mini-language to replace triples.<div><div><br></div><div>The main problems with triples IMHO which motivate this are:</div><div><br></div><div> - The vendor field is vague and non-orthoganal.</div><div> - Triples don't represent subtarget attributes, except in the way that</div><div> subtarget attributes are sometimes mangled into the architecture field</div><div> in confusing ways.</div><div><br></div><div>At an initial read, the targetspec proposal's solutions to these</div><div>problems seem reasonable.</div><div><br></div><div>It's a little surprising to have a dedicated "Byte Order" field. One</div><div>possible reason for it is that mips.le.* is marginally nicer than</div><div>mipsel.*, however that's not obviously worth burdening everyone else</div><div>for. Another possible reason is to allow otherwise</div><div>architecture-independent strings to encode an endianness. However,</div><div>that's not a concept that LLVM currently has. And without more</div><div>targetdata parts, it's not obvious how useful it is by itself.</div><div><br></div><div>On the other hand, if "Byte Order" makes sense to include, should</div><div>other parts of targetdata be included? Pointer size seems the next</div><div>most desirable -- endianness and pointer size would be sufficient for</div><div>many elf tools, for example. However, the other parts of</div><div>targetdata could conceivably be useful too.</div><div><br></div><div>The "OS" field seems like it should be renamed to "ABI", since in the</div><div>description you discuss actual OS's that support multiple ABIs.</div><div><br></div><div>In the "Feature Delta" field, using "+" to add features but using</div><div>a charactar other than "-" to remove them is unfortunate. How about</div><div>just prohibiting "-" in CPU names? Or for another idea, how about</div><div>prefixing negative features with "no-", as in "core2+sse41+no-cmov"?</div><div><br></div><div>Dan</div><div><br></div></div></div></body></html>