[llvm-dev] How to find out the default CPU / Features String for a given triple?

[Renato Golin via llvm-dev]

On Thu, 23 Jan 2020 at 06:49, Andrew Kelley via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> When I pass an empty string for cpu and features to createTargetMachine,
> and then use LLVMGetTargetMachineCPU() and
> LLVMGetTargetMachineFeatureString() to get the strings back, they are
> still empty. Is there a way to have llvm compute the effective
> cpu/features string, and provide it so that I can inspect it?

Hi Andrew,

These are the supported features for AArch64:
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/AArch64TargetParser.def


> As an example, I have a test passing in the CI using the triple
> "aarch64v8.1a-unknown-linux-unknown", and "" for both CPU name and
> target features string.

"aarch64v8.1a" doesn't exist.

Target and Arch are two different things. The target is for example
"aarch64-linux-gnu" while arch (not CPU) is "armv8.1-a" (not "v8.1a").

CPU are their literal names, like "cortex-a53".

IIRC, we allow adding modifiers like "+sve" to CPU for compatibility,
but they should be used when defining the arch, not CPU.

Unfortunately, we don't have control over the triples and arches and
have to support what vendors and prior tools do.


> However when I pass the following target
> specific features string, I get qemu crashing in the CI:

That error message has a lot more than what's accepted for
target/arch/cpu/flags. There are a lot of target specific flags in
there, which I'm not even sure they would parse in a target string at
all.

Unfortunatelly, without knowing how QEMU is using that or where the
error comes from, it's hard to tell what that means.


> Now, I understand that qemu crashing can be fixed by using a newer qemu
> version. And, indeed, on my laptop with a newer qemu, the test passes.
> However, this test was previously passing on the CI, which means that
> with this explicit string of target specific features, *something is
> different*. I am trying to determine what that different thing is.

That string is invalid. It's possible either QEMU or LLVM supported it
by either error or legacy and that's no longer true?

I'm surprised a newer QEMU somehow understands that, but without
understanding your infrastructure, what the test is and how it's
built, where does LLVM fit into all that, etc. it's hard to have any
idea what's going on.

cheers,
--renato