Andarwinux wrote: > > As for MOPS, I'm just concerned that -mcpu=c1-* will result in memcpy and > > memset to be inlined unconditionally, which according to Arm's errata will > > result in performance degradation, > > On the other hand, if someone explicitly writes a MOPS instruction in > assembly language, it shouldn't fail to assemble. The questions of "does the > CPU understand this instruction?" and "is it a good idea to use it in code > generation?" are conceptually separate.
But at the moment llvm doesn't seem to be able to distinguish between the two. I think a tune option could be added to avoid preferring MOPS in code generation, similar to x86's “FeatureFSRM”. > We do have a convention for CPUs, agreed with the Arm GNU team as we want CPU > features to be consistent as possible across toolchains, that for each Arm > CPU we enable all optional features (like SME), with crypto being the > exception of always being opt-in. This is partly historical as GCC has always > modelled it that way and crypto extensions are subject to export control. > > I understand that a lot of this will look inconsistent externally. > > As statham-arm mentions we want to separate what features the CPU supports > from whether it is the right thing to do to make use of them. Well, that makes sense. And it seems unlikely that there will be actual products that indeed don't have C1-SME2. But I'm still concerned that this will cause people to avoid using `-mcpu=c1-*`, just as Qualcomm's SoCs with Armv9 Cortex disabled SVE, so that `-mcpu=cortex-*` binaries can't be executed on `cortex-*`. https://github.com/llvm/llvm-project/pull/171124 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
