[PATCH] D64193: [PowerPC] Add exception constraint to FP rounding operations

[EsmeYi via Phabricator via llvm-commits]

Esme added inline comments.


================
Comment at: llvm/test/CodeGen/PowerPC/vector-constrained-fp-intrinsics.ll:6587
 ; PC64LE-NEXT:    lvx 2, 0, 3
+; PC64LE-NEXT:    frin 0, 0
+; PC64LE-NEXT:    frin 0, 1
----------------
steven.zhang wrote:
> andrew.w.kaylor wrote:
> > qiucf wrote:
> > > steven.zhang wrote:
> > > > This is not right. It seems that, we are still returning the rounded constant with compiler folding which didn't respect the round mode. What we did now, is just re-run the calculation to make sure that, the hw status register is updated correctly. But the result is still wrong. 
> > > D72930 introduced const-folding for these rounding ops. That looks reasonable since it doesn't depend on rounding mode and won't raise exceptions.
> > > 
> > > So it seems to be safe to delete these strict-fp ops? (they have extra operand to chain so they can't be removed automatically) Will this be an improvement?
> > > 
> > > cc: @kpn @andrew.w.kaylor 
> > They are not folded in all cases. If the input values can raise an exception (such a invalid), the operation is not folded.
> ok. We can still go with this patch and revisit this case later to see why frin is still there.
I think results here are reasonable. In EarlyCSE, constrained rounding ops may be constant-folded if they don't raise FP exceptions, but the dead code will not be deleted because they are still treated as `mayThrow`. Since these ops are matched to HW instructions with the flag `mayRaiseFPException` now, it should be reasonable to not eliminate them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64193