[llvm] r206228 - [ARM64][MC] Set the default CPU string to generic.

[Filip Pizlo]

On April 22, 2014 at 10:35:14 AM, Tim Northover (t.p.northover at gmail.com) wrote:

>>> 4.) Revert this change 
>>> This change has been actively discussed on the mailing list 
>>> (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140414/212869.html) 
>>> and IRC. This seemed to be the best approach especially with the merge with 
>>> aarch64. 
>> 
>> and would be actively against this. 
> 
> In the future, would you also be actively against reverting other changes 
> that break WebKit? 

Surely the only sane answer to that is that it should be decided on a 
case-by-case basis, with WebKit's requirements being one of the 
factors in that process. 
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.



In this case, personally, I don't see the desire for one less API call 
to be particularly compelling. 
It's compelling from the standpoint of not scaring your clients.

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.

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.

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!

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.

In the future, I would hope that such changes are reverted until a proper fix is in place.

-Filip





Cheers. 

Tim. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140422/2eb96234/attachment.html>