This is an archive of the discontinued LLVM Phabricator instance.

[flang] add -f[no-]trapping-math
AbandonedPublic

Authored by tblah on Nov 21 2022, 2:57 AM.

Details

Summary

Only add the option processing and store the result. No attributes are added to FIR yet.

Clang handles this option using -ffp-exception-behavior (and so never passes -fno-trapping-math to the frontend). We don't do that here because gfortran doesn't support -ffp-exception-behavior and I want to keep the scope limited to allow -ffast-math support to progress.

The change to the condition for forwarding -mreassociate is to match Clang.

Diff Detail

Event Timeline

tblah created this revision.Nov 21 2022, 2:57 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: mehdi_amini. · View Herald Transcript
tblah requested review of this revision.Nov 21 2022, 2:57 AM
kiranchandramohan requested changes to this revision.Nov 21 2022, 3:26 AM

Since this flag does not directly map to an MLIR Operation or LLVM Instruction fast attribute, I think we need to have an understanding of how to model this in FIR/MLIR or how to generate code in the Flang Lowering code.

flang/test/Driver/flang_fp_opts.f90
14

This flag is implemented now, right?

This revision now requires changes to proceed.Nov 21 2022, 3:26 AM
tblah added inline comments.Nov 21 2022, 3:52 AM
flang/test/Driver/flang_fp_opts.f90
14

@vzakhari didn't want to remove these warnings when support was first added because the intrinsics simplification pass still ignored fastmath (https://reviews.llvm.org/D137391#3908424).

There has been work on the intrinsics since then in https://reviews.llvm.org/D138048 but I don't know if this is complete. @vzakhari would you like me to remove these warnings for the implemented flags now?

tblah edited the summary of this revision. (Show Details)Nov 21 2022, 3:54 AM
tblah added a comment.EditedNov 21 2022, 6:16 AM

Since this flag does not directly map to an MLIR Operation or LLVM Instruction fast attribute, I think we need to have an understanding of how to model this in FIR/MLIR or how to generate code in the Flang Lowering code.

This is modeled in LLVM IR by generating constrained floating point intrinsics instead of the usual floating point operations (fadd, fsub, etc). These constrained intrinsics have the fpexcept.* attributes which specify whether optimization passes are allowed to transform code in ways which could change the exception semantics of the original code. For example, a speculatively executed FP operation might generate an exception which would not have occurred in unoptimised code. All function calls done by a function using the constrained insrinsics must use the strictfp attribute. All function definitions using the constrained intrinsics must have the strictfp attribute. More information is available here https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

None of these constrained intrinsics, their attributes, nor the strictfp function attribute are in the llvm MLIR dialect so they will need to be added there. Further they will have to be added to the arithmetic dialect, and Flang will have to learn to generate these intrinsics and attributes as described.

The math dialect is a bit trickier. Maybe we should add an attribute corresponding to fpexcept, then make sure it is lowered correctly? The current math dialect operations all implement AlwaysSpeculateableImplTrait and so could be optimised in ways which are not compatible with strict floating point exceptions. Therefore the math dialect operations will have to be treated like the raw floating point operations in the math dialect and have new constrained versions added (including lowering of these).

tblah abandoned this revision.Jan 6 2023, 2:22 AM