<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="">Thanks for the clarifications, Bob!<div class=""><br class=""></div><div class="">I’ve spent some time with the head of the <a href="http://llvm.org" class="">llvm.org</a> repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases.  The patch to add v6l, therefore, seems simple enough.  I haven’t been able to test it in my usual flow, because that involves the whole swift stack.  I’m considering creating a program that links to llvm to test the behavior.  </div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal;" class="">Index: lib/Support/TargetParser.cpp</div><div style="margin: 0px; line-height: normal;" class="">===================================================================</div><div style="margin: 0px; line-height: normal;" class="">--- lib/Support/TargetParser.cpp<span class="Apple-tab-span" style="white-space:pre">      </span>(revision 257090)</div><div style="margin: 0px; line-height: normal;" class="">+++ lib/Support/TargetParser.cpp<span class="Apple-tab-span" style="white-space:pre">     </span>(working copy)</div><div style="margin: 0px; line-height: normal;" class="">@@ -401,6 +401,7 @@</div><div style="margin: 0px; line-height: normal;" class="">       .Case("v5", "v5t")</div><div style="margin: 0px; line-height: normal;" class="">       .Case("v5e", "v5te")</div><div style="margin: 0px; line-height: normal;" class="">       .Case("v6j", "v6")</div><div style="margin: 0px; line-height: normal;" class="">+      .Case("v6l", "v6")</div><div style="margin: 0px; line-height: normal;" class="">       .Case("v6hl", "v6k")</div><div style="margin: 0px; line-height: normal;" class="">       .Cases("v6m", "v6sm", "v6s-m", "v6-m")</div><div style="margin: 0px; line-height: normal;" class="">       .Cases("v6z", "v6zk", "v6kz")</div><div style="margin: 0px; line-height: normal;" class="">Index: unittests/ADT/TripleTest.cpp</div><div style="margin: 0px; line-height: normal;" class="">===================================================================</div><div style="margin: 0px; line-height: normal;" class="">--- unittests/ADT/TripleTest.cpp<span class="Apple-tab-span" style="white-space:pre">        </span>(revision 257090)</div><div style="margin: 0px; line-height: normal;" class="">+++ unittests/ADT/TripleTest.cpp<span class="Apple-tab-span" style="white-space:pre">     </span>(working copy)</div><div style="margin: 0px; line-height: normal;" class="">@@ -851,6 +851,10 @@</div><div style="margin: 0px; line-height: normal;" class="">     EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch());</div><div style="margin: 0px; line-height: normal;" class="">   }</div><div style="margin: 0px; line-height: normal;" class="">   {</div><div style="margin: 0px; line-height: normal;" class="">+    llvm::Triple Triple("armv6l-unknown-eabi");</div><div style="margin: 0px; line-height: normal;" class="">+    EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch());</div><div style="margin: 0px; line-height: normal;" class="">+  }</div><div style="margin: 0px; line-height: normal;" class="">+  {</div><div style="margin: 0px; line-height: normal;" class="">     llvm::Triple Triple("armv6j-unknown-eabi");</div><div style="margin: 0px; line-height: normal;" class="">     EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch());</div><div style="margin: 0px; line-height: normal;" class="">   }</div><div class=""><br class=""></div></div></div><div class=""><br class=""></div><div class="">I looked into the tests (and unit tests), and found that perhaps the most appropriate test to add is in the determination of the cpu type from the architecture version.  I verified that ARM1136 is the base for ARM11, which is all that can be assumed given armv6.  That jives with the existing armv6 architecture test.  I added another copy of that for armv6l.  I assume that this will sufficiently test whether armv6l is aliasing correctly to armv6.</div><div class=""><br class=""></div><div class="">Anyway, thanks again.</div><div class="">- Will</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 10:16 AM, Bob Wilson <<a href="mailto:bob.wilson@apple.com" class="">bob.wilson@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 2:21 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jan 7, 2016 at 2:17 PM William Dillon <<a href="mailto:william@housedillon.com" class="">william@housedillon.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Yikes!!<div class=""><br class=""></div><div class="">It looks like things have changed considerably!  I’ll need to start this from scratch.  A few questions, though:</div><div class=""><br class=""></div><div class="">I have a goal for this to be in the Swift 2.2 release, is that feasible?</div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div>Maybe. We’re using an older version of llvm/clang for Swift 2.2 to give us a stable platform to work with, but if you get a change into trunk first, and if it is relatively low-risk, we could consider back-porting it to the release branch for Swift 2.2. We do want to be careful to avoid destabilizing the branch, though, and the criteria for accepting changes will only get more strict over time.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">If so, will the current LLVM head end up in the branch for 2.2 when that time comes?</div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div>No. We already created the llvm/clang release branches to be used with Swift 2.2 to give us a longer time to stabilize them. We do not plan to rebranch again from trunk for Swift 2.2.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Given that the coordination costs to attempt any kind of change in swift that requires a change in LLVM are so high, I’m tempted to keep the logic of stripping the ‘l’s from armv7l and armv6l inside swift itself.  It really seems like the wrong approach, but sometimes the wrong answer is the best answer, depending on the circumstances.</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">For all of these questions you should talk to Bob Wilson who is the llvm release manager for the swift project.</div><div class=""><br class=""></div><div class="">-eric</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class="">- Will</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 10:05 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:</div><br class=""><div class=""><p dir="ltr" class="">The swift repository is old and many thousand revisions behind llvm. Please don't use it as a base when submitting to the llvm project. </p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jan 7, 2016, 10:02 AM William Dillon <<a href="mailto:william@housedillon.com" target="_blank" class="">william@housedillon.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Oops, I neglected to reply-all….<div class=""><br class=""></div><div class="">The current stable branch at github still has it:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106" target="_blank" class="">https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106</a></div></div><div class=""><br class=""></div><div class="">Should I get the head of the non-swift repository and generate a new diff?</div><div class=""><br class=""></div><div class="">Also, I suspect that it’s not a good idea to have armv6l map to armv6k, because that seems like quite an assumption to make.  Clearly, armv6 sub architectures that aren’t v6k will still be v6l in linux. (provided they’re little-endian).</div><div class="">I’ve already made that change, and it would be included in any revised diff that I send out.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Will</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 6, 2016, at 10:02 AM, Artyom Skrobov <<a href="mailto:Artyom.Skrobov@arm.com" target="_blank" class="">Artyom.Skrobov@arm.com</a>> wrote:</div><br class=""><div class=""><div class="">William, what revision of LLVM is your patch based on?<br class=""><br class="">The trunk hasn't had ARM_ARCH("armv6hl") since r252903 (Nov 12th)<br class=""><br class=""><br class="">-----Original Message-----<br class="">From: William Dillon [<a href="mailto:william@housedillon.com" target="_blank" class="">mailto:william@housedillon.com</a>] <br class="">Sent: 06 January 2016 17:55<br class="">To: Renato Golin<br class="">Cc: Tim Northover; LLVM Dev; nd; Artyom Skrobov; Daniel Sanders; Eric Christopher<br class="">Subject: Re: [llvm-dev] Diff to add ARMv6L to Target parser<br class=""><br class="">Taking the suggestions of the group under consideration, I’ve generated a new diff.  The thing to note is that armv6l is now treated identically to armv6hl.  I’ve also added a unit test.<br class="">This seems to me to be the least invasive method, and holds to existing conventions as closely as possible.<br class=""><br class="">Thoughts?<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>