<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">Thank you so much for this discussion.  It has been very helpful and educational.  I think that I understand the perspectives of both Tim and Renato.  Let me briefly summarize them to ensure that I correctly understand:</div><div class=""><br class=""></div><div class="">Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful.  :) In the case of armv7l (for example) it has a clear meaning: ARMv7A little endian.  Unfortunately, this nomenclature collides with what is used for sub-architectures.  ARMv7l, however, is NOT a sub-architecture, and should not be treated as one.</div><div class=""><br class=""></div><div class="">Tim’s perspective is that what Renato says isn’t wrong, but that while the logic currently used to map armv7l into something meaningful is not great, it is certainly not unacceptable.  Given that armv7l is already treated in this way, it is not unreasonable to also support armv6l.</div><div class=""><br class=""></div><div class="">How is this for a proposed solution?  What if I add logic to <a href="https://github.com/apple/swift-llvm/blob/stable/lib/Support/TargetParser.cpp#L387" class="">llvm::ARM::getCanonicalArchName()</a> that matches the trailing ‘l’ (or ‘b’) and treats it the same way that ‘el’ and ‘eb’ are now?  This function would return v7 or v6 in the case of armv7l or armv6l, respectively (or, if it’s preferred, v7a or v6a).  It seems like this is closer to the “correct” approach.  It does show potentially inappropriate deference to Linux’s choice in the matter, but at least it’s not making sub-architectures that don’t exist.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class="">- Will</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 4:48 AM, Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 5 January 2016 at 12:33, Tim Northover <<a href="mailto:t.p.northover@gmail.com" class="">t.p.northover@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">I know they don't make sense in many corner cases, but I think<br class="">discarding logic where it *does* exist is a mistake.<br class=""></blockquote><br class="">We're not discarding any logic. As I said, the architecture name<br class="">cannot be ARMv7L for any reason. It's that simple.<br class=""><br class="">The logic, if it exists, need to be encoded somewhere else.<br class=""><br class=""><br class=""><blockquote type="cite" class="">I do know this, Renato.<br class=""></blockquote><br class="">I only meant as an opener, not as education. I know you know this...<br class=""><br class=""><br class=""><blockquote type="cite" class="">I have no idea what you're objecting to here. I wasn't saying anything<br class="">about how GNU interprets the armv7l that would be produced, just that<br class="">I would expect running "uname" on an R-class Linux to produce armv7l.<br class=""></blockquote><br class="">I cannot separate between A and R if both use the same arch name.<br class="">Knowing the sub-arch is as important than knowing its byte-sex, and I<br class="">can't trade one for the other.<br class=""><br class="">If the Driver/Triple/Tuple knows which, depending on other<br class="">information, then they should be the ones encoding this.<br class=""><br class="">Adding an *Arch Name* ARMv7L will make no progress in understanding<br class="">what it is. Encoding the correct fields in the Triple/Tuple will, and<br class="">for that, ARMv7A or ARMv7R are the *correct* "arch names".<br class=""><br class="">cheers,<br class="">--renato<br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>