This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] fold fdiv with pow divisor (PR49147)
ClosedPublic

Authored by spatel on Feb 13 2021, 8:17 AM.

Details

Summary

This is unusual in the general (non-reciprocal) case because we need an extra instruction, but that should be better for general FP reassociation and codegen. We conservatively check for "arcp" FMF here as we do with existing fdiv folds, but it is not strictly necessary to have that.

This is part of solving:
https://llvm.org/PR49147
(The powi variant potentially has a different constraint.)

Diff Detail

Event Timeline

spatel created this revision.Feb 13 2021, 8:17 AM
spatel requested review of this revision.Feb 13 2021, 8:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 13 2021, 8:17 AM

Hm, alive2 doesn't support fast-math flags still?
Filed https://github.com/AliveToolkit/alive2/issues/667

This seems fine to me.

llvm/test/Transforms/InstCombine/fdiv.ll
698

Might be worth duplicating the test with reassoc missing instead?

Hm, alive2 doesn't support fast-math flags still?
Filed https://github.com/AliveToolkit/alive2/issues/667

Thanks! Yes, I think Alive2 knows how to handle the "special value" FMF (ninf, nnan, nsz), but not these math properties.

llvm/test/Transforms/InstCombine/fdiv.ll
698

Yes, good point - or I can just have both variants (only reassoc and only arcp). If we change our FMF fdiv constraints in the future, we'll have coverage in either direction.

llvm.powi ?

llvm.powi ?

Sorry - just read your comment on PR49147. Could we at least support inrange constant ints?

spatel updated this revision to Diff 323562.Feb 13 2021, 10:31 AM

Added another test for FMF.

lebedev.ri accepted this revision.Feb 13 2021, 10:35 AM

Looks good to me.

This revision is now accepted and ready to land.Feb 13 2021, 10:35 AM

llvm.powi ?

Sorry - just read your comment on PR49147. Could we at least support inrange constant ints?

We could do that, but it won't solve the example in the bug report. I think we need to check if the call has an fdiv use and suppress the conversion to powi in SimplifyLibCalls:

// powf(x, itofp(y)) -> powi(x, y)

...or fold the whole pattern at once.

Otherwise, we lose information when we fold the cast into the call. Either way, I think we want to do that in an independent patch. I can work on that next.

spatel marked an inline comment as done.Feb 13 2021, 10:40 AM
RKSimon accepted this revision.Feb 13 2021, 10:57 AM

OK cheers - lets go with this first to get the pow variant dealt with

This revision was automatically updated to reflect the committed changes.