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

[Andrew Kelley via llvm-dev]

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?

I'm trying to figure out how the cpu/features string that I am
explicitly passing, which I am expecting to be equivalent to passing
empty string, is different.

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. However when I pass the following target
specific features string, I get qemu crashing in the CI:

-a35,-a53,-a55,-a57,-a72,-a73,-a75,-a76,-aes,-aggressive-fma,-alternate-sextload-cvt-f32-pattern,+altnzcv,+am,-arith-bcc-fusion,-arith-cbz-fusion,-balance-fp-ops,+bti,-call-saved-x10,-call-saved-x11,-call-saved-x12,-call-saved-x13,-call-saved-x14,-call-saved-x15,-call-saved-x18,-call-saved-x8,-call-saved-x9,+ccdp,+ccidx,+ccpp,+complxnum,+crc,-crypto,-custom-cheap-as-move,-cyclone,-disable-latency-sched-heuristic,+dit,+dotprod,-exynos-cheap-as-move,-exynosm1,-exynosm2,-exynosm3,-exynosm4,-falkor,+fmi,-force-32bit-jump-tables,+fp-armv8,-fp16fml,+fptoint,-fullfp16,-fuse-address,+fuse-aes,-fuse-arith-logic,-fuse-crypto-eor,-fuse-csel,-fuse-literals,+jsconv,-kryo,+lor,+lse,-lsl-fast,+mpam,-mte,+neon,-no-neg-immediates,+nv,+pa,+pan,+pan-rwv,+perfmon,-predictable-select-expensive,+predres,-rand,+ras,+rasv8_4,+rcpc,+rcpc-immo,+rdm,-reserve-x1,-reserve-x10,-reserve-x11,-reserve-x12,-reserve-x13,-reserve-x14,-reserve-x15,-reserve-x18,-reserve-x2,-reserve-x20,-reserve-x21,-reserve-x22,-reserve-x23,-reserve-x24,-reserve-x25,-reserve-x26,-reserve-x27,-reserve-x28,-reserve-x3,-reserve-x4,-reserve-x5,-reserve-x6,-reserve-x7,-reserve-x9,-saphira,+sb,+sel2,-sha2,-sha3,-slow-misaligned-128store,-slow-paired-128,-slow-strqro-store,-sm4,-spe,+specrestrict,+ssbs,-strict-align,-sve,-sve2,-sve2-aes,-sve2-bitperm,-sve2-sha3,-sve2-sm4,-thunderx,-thunderx2t99,-thunderxt81,-thunderxt83,-thunderxt88,+tlb-rmi,-tpidr-el1,-tpidr-el2,-tpidr-el3,+tracev8.4,-tsv110,+uaops,-use-aa,+use-postra-scheduler,-use-reciprocal-square-root,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8.5a,+vh,-zcm,-zcz,-zcz-fp,-zcz-fp-workaround,-zcz-gp

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.

Thanks in advance for the help,
Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200123/899e818a/attachment.sig>