[llvm] r206211 - [ARM64][MC] Set the default CPU to cyclone when initilizating the MC layer.

Quentin Colombet qcolombet at apple.com
Thu Apr 17 11:04:25 PDT 2014


Hi Andy,

On Apr 16, 2014, at 12:58 PM, Andrew Trick <atrick at apple.com> wrote:

> 
> On Apr 16, 2014, at 12:37 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
>>> Of course a target should be able to provide a cpu type called “generic" if
>>> it wants to. If the driver for some platform decides to use “generic” as the
>>> default, that’s fine with me. For ARM64, “generic" doesn’t seem very useful
>>> except to test certain features of the backend, and certainly should not be
>>> a default.
>> 
>> That "except" is rather important to me. I'd really rather not have to
>> remember to specify a valid "-mcpu" every time I execute llc, if I
>> understand you correctly. I'm annoyed enough by the regular intrusion
>> of "-mattr=neon" and friends.
>> 
>> I suppose if anything I'd want llc to choose a maximal sensible CPU
>> rather than a minimal one. Possibly with its own logic.
> 
> You’re asking for logic to pick a platform-specific default to be in a library that can be used by both clang and llc. That sounds great to me, as long as clang/llc are consistent. It’s just more work than forcing llc to take explicit options and less important to me.
I share Tim’s concerns. Having to specify a cpu on every llc command line sounds annoying. Now regarding the default choice, this was discussed on IRC and generic is the only target in the ARM64 backend that is not apple-specific.

That said, I am happy to work toward a consensus.

Regarding the idea of having a library that both llc and clang would share, I am not sure what you meant here.
Could you elaborate?

Note: We kill the CPU auto detection feature to avoid the bad surprises within the tests when switching environments. If we go toward such a library, we must not replicate this. Therefore, I am not sure how useful that would be for clang.

Cheers,
-Quentin

> 
> -Andy
> 
>> Cheers.
>> 
>> Tim.
> 





More information about the llvm-commits mailing list