rj-jesus wrote: > This should be left on. People can use -mcpu=neoverse-v2+norng if they don't > have it. Lots of features can be disabled for many different reasons.
Hi, I assume the intent of having it on is to enable the usage of the random number generator intrinsics gated by some form of runtime detection? If so, should that not still be possible with `-mcpu=neoverse-v2+rng`, which might better convey that the runtime detection is indeed _necessary_ and shouldn't be presumed? AFAICT the availability of the rng intrinsics in CPUs that do not support them is not specified (or at least I couldn't find it), which can lead to attempts to execute illegal instructions from what looks like reasonable source code. From the [ACLE](https://github.com/ARM-software/acle/blob/main/main/acle.md#random-number-generation-extension): > __ARM_FEATURE_RNG is defined to 1 if the Random Number Generation > instructions are supported and the intrinsics defined in [Random number > generation > intrinsics](https://github.com/ARM-software/acle/blob/main/main/acle.md#random-number-generation-intrinsics) > are available. There doesn't seem to be any other conditions under which __ARM_FEATURE_RNG is defined, which---unless I'm misunderstanding or missing something---seems to suggest the instructions should be available unconditionally alongside the intrinsics. > If Grace doesn't have it then maybe that should apply just to Grace, and we > split the configs into two? Yeah, I forgot to mention it earlier, the problem with going this route is that it will still misbehave with `-mcpu=native`. AFAIU `getHostCPUFeatures` is mainly used to enable features when we find them, not to disable them when we don't (at least I couldn't do so trivially when I gave it a try). If we go this route, we may need to add some means for excluding extensions like `rng`, or define a "base" Neoverse V2 spec without crypto and rng and use that with `-mcpu=native`. Neither option sounded great, but please let me know if there's something else I should try. https://github.com/llvm/llvm-project/pull/166387 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
