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

Filip Pizlo fpizlo at apple.com
Tue Apr 22 09:56:01 PDT 2014


I don't like any option that requires the JIT client to specify the CPU type when JITing with intent to run in-process (i.e. the default). This just adds even more noise to the already-confusing MCJIT APIs.

On April 22, 2014 at 9:30:48 AM, Eric Christopher (echristo at gmail.com) wrote:

>> To fix this we could:
>> 1.) Extend the C interface to also specify the CPU type and warn JIT clients that don’t specify a CPU for ARM64
> This looks like the right approach to me.
> The clients of the backend should not rely on any default CPU.
It's the wrong approach.  The JIT default is to produce code that runs in the process.  The client of the C interface shouldn't have to tell LLVM what the right processor is for the process in which LLVM is running and for which LLVM is generating code.


>
> What is the current behavior on X86?
>>
>> 3.) Every JIT client has to add the target processor attribute to the IR
> That sounds like a good safe belt, especially to reproduce failures (see http://llvm.org/bugs/show_bug.cgi?id=19483). That said, how this attribute is propagated?
> In particular does ARM64 backend do the right thing if you set it.
>
I'm not sure I understand this option.



I definitely like both of these options...

>> 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?

-Filip





-eric

_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140422/e3908ad0/attachment.html>


More information about the llvm-commits mailing list