This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombine] Remove the check for unsafe-fp-math when we are checking the AFN
ClosedPublic

Authored by steven.zhang on Dec 29 2020, 12:32 AM.

Details

Summary

Happen to see this issue. We are checking the unsafe-fp-math for sqrt but not for fpow, which behaves inconsistent. As the direction is to remove this global option, I tried to remove the unsafe-fp-math check for sqrt and update the test with afn fast-math flags.

Diff Detail

Event Timeline

steven.zhang created this revision.Dec 29 2020, 12:32 AM
steven.zhang requested review of this revision.Dec 29 2020, 12:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 29 2020, 12:32 AM
Herald added a subscriber: wdng. · View Herald Transcript

We're trying to (very slowly...) move away from needing the global/target options. Also, I'm not sure how those translate with GlobalISel.
If there's a real-world case where the target options do not match the fast-math-flags on the IR, we should investigate if that was unexpected. Otherwise, I would prefer that we not add to the uses of target options.

We're trying to (very slowly...) move away from needing the global/target options. Also, I'm not sure how those translate with GlobalISel.
If there's a real-world case where the target options do not match the fast-math-flags on the IR, we should investigate if that was unexpected. Otherwise, I would prefer that we not add to the uses of target options.

Hmm, do you know the specific reason that it is removed so slowly ... (What I imagine is just removing it and update some tests. Some targets still want it ?) It is not right to me that it is handled inconsistent. i.e.
FPOW didn't check the unsafe-fp-math while SQRT check it.

As the direction is to remove this option, I tried to remove the unsafe-fp-math for sqrt to make the check for afn consistent in LLVM. I could do more but I am afraid I miss some background that stop this removal ...

steven.zhang retitled this revision from [DAGCombine] Respect the unsafe-fp-math when perform the transformation of fpow() to [DAGCombine] Remove the check for unsafe-fp-math when we are checking the AFN.
steven.zhang edited the summary of this revision. (Show Details)

We're trying to (very slowly...) move away from needing the global/target options. Also, I'm not sure how those translate with GlobalISel.
If there's a real-world case where the target options do not match the fast-math-flags on the IR, we should investigate if that was unexpected. Otherwise, I would prefer that we not add to the uses of target options.

Hmm, do you know the specific reason that it is removed so slowly ... (What I imagine is just removing it and update some tests. Some targets still want it ?) It is not right to me that it is handled inconsistent. i.e.
FPOW didn't check the unsafe-fp-math while SQRT check it.

Some targets had concerns about relying on only the node-level FMF, but I don't remember exactly why. It's been a long time since we introduced that functionality, so maybe it's fine to update now.
@arsenm - thoughts? (also adding more people who might answer if/how FMF changes affect GlobalIsel)

As the direction is to remove this option, I tried to remove the unsafe-fp-math for sqrt to make the check for afn consistent in LLVM. I could do more but I am afraid I miss some background that stop this removal ...

I agree that we should be consistent, so I agree with the updated patch.

We're trying to (very slowly...) move away from needing the global/target options. Also, I'm not sure how those translate with GlobalISel.
If there's a real-world case where the target options do not match the fast-math-flags on the IR, we should investigate if that was unexpected. Otherwise, I would prefer that we not add to the uses of target options.

It does make a difference in a few contexts where we don't have flags (e.g. function arguments)

We're trying to (very slowly...) move away from needing the global/target options. Also, I'm not sure how those translate with GlobalISel.
If there's a real-world case where the target options do not match the fast-math-flags on the IR, we should investigate if that was unexpected. Otherwise, I would prefer that we not add to the uses of target options.

Hmm, do you know the specific reason that it is removed so slowly ... (What I imagine is just removing it and update some tests. Some targets still want it ?) It is not right to me that it is handled inconsistent. i.e.
FPOW didn't check the unsafe-fp-math while SQRT check it.

Some targets had concerns about relying on only the node-level FMF, but I don't remember exactly why. It's been a long time since we introduced that functionality, so maybe it's fine to update now.
@arsenm - thoughts? (also adding more people who might answer if/how FMF changes affect GlobalIsel)

GlobalISel should behave identically to the DAG. We have the fast math flags, and could access the same TargetMachine options.

Hmm, so we can try to remove those parts that not relative with the parameter arsenm mentioned. I guess most of the check in the DAGCombiner could be removed if I understand correctly. To remove it completely, some work is needed for parameters or others that current IR cannot represent the semantics of the global setting. Is it right ?

Maybe, we can start it with this simple patch first ?

spatel accepted this revision.Jan 6 2021, 8:01 AM

Hmm, so we can try to remove those parts that not relative with the parameter arsenm mentioned. I guess most of the check in the DAGCombiner could be removed if I understand correctly. To remove it completely, some work is needed for parameters or others that current IR cannot represent the semantics of the global setting. Is it right ?

Maybe, we can start it with this simple patch first ?

That sounds right to me, so LGTM.
We will need to allow FMF on any FP value (including loads and arguments) to finally get rid of the global options. We added FMF on phi/select in IR over a year ago, but it doesn't go far enough to handle cases like:
https://bugs.llvm.org/show_bug.cgi?id=35607#c9
(also see the related bugs for more background).

This revision is now accepted and ready to land.Jan 6 2021, 8:01 AM