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

[Andrew Trick]

On Apr 22, 2014, at 9:56 AM, Filip Pizlo <fpizlo at apple.com> wrote:

> 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.
> 
Of course. This is an obvious MCJIT deficiency:

llvm.org/PR19510 - MCJIT should provide a mechanism for detecting the target and cpu type based on the host. 

But I think we should have a solution that doesn’t depend on that feature.

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

If you add IR attributes as such:

define void foo() #0 {}
attributes #0 = { nounwind "target-cpu”="cyclone”}

That CPU string will override the current “generic” default. That in-turn can be overridden with -mpu=xxx.

That will probably just work. It just isn’t a feature that clang uses—although LTO should use it someday.

—

We might *also* want to provide a C API to set the CPU. I personally think the JIT client should be forced to specify a CPU until we have the aforementioned auto-detect feature. The default of “generic” is simply wrong. However, this needs to be balanced with breaking API compatibility.

-Andy

>> 
>> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits