<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br><p style="color:#000;">On April 22, 2014 at 10:35:14 AM, Tim Northover (<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>) wrote:</p> <div><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div></div><div>>>> 4.) Revert this change<span class="Apple-converted-space"> </span><br>>>> This change has been actively discussed on the mailing list<span class="Apple-converted-space"> </span><br>>>> (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140414/212869.html)<span class="Apple-converted-space"> </span><br>>>> and IRC. This seemed to be the best approach especially with the merge with<span class="Apple-converted-space"> </span><br>>>> aarch64.<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> and would be actively against this.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> In the future, would you also be actively against reverting other changes<span class="Apple-converted-space"> </span><br>> that break WebKit?<span class="Apple-converted-space"> </span><br><br>Surely the only sane answer to that is that it should be decided on a<span class="Apple-converted-space"> </span><br>case-by-case basis, with WebKit's requirements being one of the<span class="Apple-converted-space"> </span><br>factors in that process.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>In the case of the C API, I think it's better to have a hard line. It's a stable API. It shouldn't be broken.</p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div><br><br>In this case, personally, I don't see the desire for one less API call<span class="Apple-converted-space"> </span><br>to be particularly compelling.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div></div><p>It's compelling from the standpoint of not scaring your clients.</p><p>The C API is meant to be LLVM's stable API. The point of stable API is that you go to some effort to preserve its stability. Arguing that an already relied-upon API can be broken at any time is very disturbing to me as a client of the API.</p><p>But also, arguing that a JIT client should make a call to explicitly tell the JIT to target the CPU that the process is running on is silly. The JIT already knows the CPU that it's running on and it already makes a bunch of decisions to that effect, like defaulting to a memory manager and runtime dyld that will install code within the current process. Hence the JIT should also set the CPU to the CPU it's running on. Anything else is confusing. Note that I'm not arguing that the MC backend should set the default - I'm saying that the JIT's setup code should do it.</p><p>That said, my main beef here is that whatever aesthetic preference you have - even if you *love* having every JIT client have to add even more boilerplate to set the CPU - it represents a breaking change to stable API. We shouldn't allow that!</p><p>I would argue that this change was buggy in that it didn't modify the MCJIT's set-up code to configure the CPU so that JIT clients don't have to change their code.</p><p>In the future, I would hope that such changes are reverted until a proper fix is in place.</p><p>-Filip</p><p><br></p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div><br><br>Cheers.<span class="Apple-converted-space"> </span><br><br>Tim.<span class="Apple-converted-space"> </span><br></div></div></span></blockquote></div></body></html>