[PATCH] D24661: More processors support under AARch64 state for auto detection.

[Suprateeka R Hegde via llvm-commits]

On 20-Sep-2016 09:44 PM, James Greenhalgh wrote:
> jgreenhalgh added a subscriber: jgreenhalgh.
>
> ================ Comment at: lib/Target/AArch64/AArch64.td:259 @@
> +258,3 @@ +                                   "AppliedMicro (APM)
> X-Gene-1 processors", [ + FeatureCRC, + FeatureFPARMv8,
> ---------------- This disagrees with the GCC implementation of
> -mcpu=xgene1 and the xgene-1 processors available in the GCC compile
> farm (gcc113.osuosl.org is an APM X-Gene Mustang board). Are you
> sure that the CRC feature should be enabled?

Yes. I am sure. Only the crypto (optional as per ARMv8-A specs) is
missing on the first version of X-Gene (xgene1).

Are you talking about making it default? In that case I am OK with
wither -mcpu=xgene1+crc (explicitly mention) or -mcpu=xgene1 (implicit;y
enable CRC).

BTW, this need not match with GCC. Its all about documentation later on.

Let me know if you have any preference. I shall make it that way.

On 20-Sep-2016 10:48 PM, Renato Golin wrote:
> I totally understand, but given the non-critical nature of this
> feature, I'd rather do it the right way from the beginning, than
> having something hacked up now and move later.

Lets do the libcpu part later. I have some bigger ideas and requirement
on those lines. I am working on that (but not yet prioritized). One of
the System V Generic ABI proposals/discussion I started, is related to
this. I could not pursie it then, I shall re-open that very soon. Then I
shall do this libcpu too. Read more about the gABI/x86-64 discussion 
here: https://goo.gl/zlD1Qd

Basically, that would provide headers and APIs both for compile time, 
runtime and for ELF.

> None of them outline their licenses well enough for us to re-use /
> incorporate.

I didnt mean to re-use. We (I) will write it afresh under LLVM license.

So for now, I shall make the changes asked by Tim (making a static 
array). I assume this is acceptable. Please let me know. And if you are 
OK with that, let me know your preference on what I asked:

---
> Do you prefer separate ones under __aarch64__ and __arm__ or club both __arm__ and __aarch64__ together into one?
>
> (I dont think the "CPU Part Number" would ever repeat/overlap across __arm__ and __aarch64__. So we may club it together)
---

What is better in your opinion?

--
Supra