Details
Diff Detail
Unit Tests
Event Timeline
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | I think we need a nofpexcept flag check for most of these FP ops |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | Do we realy raise anything? I suppose at maximum we will get SNaN, but that can be remated. On practice have you seen a signaling scenario anywhere? |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | It's not enabled anywhere but the hardware does support it. You just need to check MI::mayRaiseFPException |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | If I just check it these will never be remated, there is no even a point to mark them. If the check will include something like "exceptions enabled for the functuon and may raise", then it makes more sense. But since we don't enable it I doubt I can write such check. Maybe just leave a TODO? |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | I can even add a stub areFPEcxeptionsEnabled() returning false in the MFI, and check it. One day we will write something into that stub. |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | You don't need to track a function level property. The regular non-constrained FP operations imply nofpexcept. You just need to check MI::mayRaiseFPException |
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | Ack. |
Added check for mayRaiseFPException().
llvm/lib/Target/AMDGPU/VOP1Instructions.td | ||
---|---|---|
361 | Note that we do not always set nofpexcept even though we have it disabled. Selection could be improved. |
I think we need a nofpexcept flag check for most of these FP ops