[PATCH] D85548: Allow fneg + strict_fadd -> strict_fsub in DAGCombiner

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In D85548#2223973 <https://reviews.llvm.org/D85548#2223973>, @spatel wrote:

> In D85548#2223912 <https://reviews.llvm.org/D85548#2223912>, @arsenm wrote:
>
>> In D85548#2223906 <https://reviews.llvm.org/D85548#2223906>, @spatel wrote:
>>
>>> Why wait until codegen to do this? IIUC, it's impossible for any backend to spontaneously create strict FP ops, so this pattern must be present in the original IR.
>>> Ie, wouldn't we be better off reducing these in IR (InstCombinerImpl::visitCallInst())?
>>
>> It doesn't matter if instcombine does this or not, this pattern could still easily appear after legalization
>
> Ok, I haven't followed strict FP closely, so my assumption was wrong. Is there a test or example somewhere that shows how a strict fadd is created out of something else?

You may need to expand strict FP operations in terms of other strict FP operations. If I were to seriously try to implement strictfp for AMDGPU, it would look like a lot of expansions with other strict operations. I think this is too much effort for SelectionDAG, but is more manageable for GlobalISel.

Also, in general, codegen may need more relaxed rules for mixing strict and non-strict FP operations (at least in GlobalISel where there's an explicit instruction ordering). For example, AMDGPU's non-strict fdiv lowering needs to introduce mode switches (which in the DAG we use custom strict FP nodes with glue)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85548/new/

https://reviews.llvm.org/D85548