andrewcarlotti wrote: I think the existing situation before FMV was already a bit confusing.
We have the command line feature `+memtag`. This enables all the instructions specified in FEAT_MTE and FEAT_MTE2. Note that the FEAT_MTE2 instructions aren't available at EL0. With `-mcpu=neoverse-v2` in either GCC or LLVM, we enable `+memtag` by default. (I think this applies to all CPUs with memtag support). The actual CPU always supports the FEAT_MTE instructions, but it can only support FEAT_MTE2 if other parts of the system include support for it. So this would suggest that the `+memtag` flag corresponds to FEAT_MTE, with the non-EL0 FEAT_MTE2 instructions requiring the user to check that they're actually supported by the target system. In contrast, HWCAP_MTE is enabled in the Linux kernel only when support exists for FEAT_MTE2. This means that the HWCAP doesn't directly match the command line flag. I think this difference would be ok in practice, since I can't imagine any scenario in which it would be beneficial to choose a `+memtag` version of a function when FEAT_MTE2 is not supported. However, if we include `+memtag` in FMV with this discrepancy, then we do have to be careful to avoid indirection elimination optimisations that assume that a function with `+memtag` enabled (via the command line or attributes) will always call a `"memtag"` function version at runtime. https://github.com/llvm/llvm-project/pull/109299 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
