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

Filip Pizlo fpizlo at apple.com
Tue Apr 22 11:22:38 PDT 2014

On April 22, 2014 at 11:09:40 AM, Tim Northover (t.p.northover at gmail.com) wrote:

> No, I'm saying that the default CPU in the JIT should always be the CPU 
> we're actually running on. That's not insane, that's how any sensible JIT 
> would work. 

Possibly (though the lldb developers may quibble about their JIT not 
being sensible).
Sure, but lldb already manually sets the CPU.

The question here is what behavior to give to those who don't manually set the CPU.  I'm arguing that the API previously guaranteed that the JIT would target the CPU flavor that the process was running on, and that we should arrange for the JIT to continue to obey this in the case that the JIT's client doesn't manually set the CPU.

 That wasn't the behaviour before though, it just 
randomly picked Cyclone for the giggles. 

The expected behavior that a JIT client has is that by default, the JIT correctly targets the native CPU.  Previous to this change, if you were on Cyclone, the JIT was obeying that contract with its client.  It was doing so because of a hack rather than intelligence.  But it *was* doing the right thing from the standpoint of the client.

Hence, this change broke the JIT's behavior on Cyclone.  It probably also fixed behavior on other flavors.  But I hope we can all agree that breaking one platform to fix another isn't exactly the kind of engineering ethos we should strive for.  Instead, we should try to fix both Cycone and non-Cyclone by doing what I suggest inside the JIT's setup code.

In the future, if someone does break one platform to fix another - especially when it involves stable API, and where it's clear what the right fix is - then we should revert to avoid a situation where clients have to blacklist a series of LLVM revisions.


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

More information about the llvm-commits mailing list