davemgreen wrote: Hi - I went looking at out internal tracker for what happened the last time we enabled strictfp for AArch64. This was the list of patches mentioned, there might have been some more either before these or some minor fixups. ``` 94843ea7d7e5 [AArch64] Make machine combiner patterns preserve MIFlags 6f53960d6416 [AArch64] Adjust machine-combiner-reassociate.mir test bca998ed3c9a [AArch64] Generate fcmps when appropriate for neon intrinsics 0d8092dd485a [AArch64] Fix legalization of v1f64 strict_fsetcc and strict_fsetccs d4342efb6959 [AArch64] Add instruction selection for strict FP 9d68ed08178d [AArch64] Allow strict opcodes in fp->int->fp patterns b670da798d35 [AArch64] Allow strict opcodes in indexed fmul and fma patterns d916856bee11 [AArch64] Allow strict opcodes in faddp patterns 8e17c9613f36 [AArch64] Add some missing strict FP vector lowering bbd7eac800e6 [AArch64] Remove an unused variable in my previous patch 12c1022679d4 [AArch64] Lowering and legalization of strict FP16 1b1466c34669 [AArch64] Adjust aarch64 constrained intrinsics tests and un-XFAIL 27a8735a444f [AArch64] Add mayRaiseFPException to appropriate instructions 88ac25b357aa [MachineCSE] Allow PRE of instructions that read physical registers 2d8c1597e51c [MIRVRegNamer] Avoid opcode hash collision 49510c50200c [AArch64] Mark all instructions that read/write FPCR as doing so 9e3264ab2021 [FPEnv] Enable strict fp for AArch64 in clang ```
We would probably need something similar for Arm - it is worth not underestimating the amount of work we would need to do, but if you are happy to try and push it through we would need to handle all the strict variants of the instructions and add mayRaiseFPException/FPCR to the relevant places. https://github.com/llvm/llvm-project/pull/137101 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
