This is an archive of the discontinued LLVM Phabricator instance.

Mark arith.minf, arith.maxf as commutative.
ClosedPublic

Authored by csigg on Jan 11 2022, 4:13 AM.

Diff Detail

Event Timeline

csigg created this revision.Jan 11 2022, 4:13 AM
csigg requested review of this revision.Jan 11 2022, 4:13 AM
herhut accepted this revision.Jan 11 2022, 6:07 AM

Thanks!

This revision is now accepted and ready to land.Jan 11 2022, 6:07 AM

Just a drive through question, Is this valid when there are NaNs? Should this be restricted to situations like fast math?

+1, this also gets interesting with +0 and -0. It is possible to do this, but then backends will need to work harder to ensure this behavior. Could you add motivation to description here?

This revision was automatically updated to reflect the committed changes.

The arith::minf operation is defined as

Returns the minimum of the two arguments, treating -0.0 as less than +0.0.
    If one of the arguments is NaN, then the result is also NaN.

which makes it commutative.

The motivation is to put constants on the right, so that parts of the minf/maxf expansion with constants can be folded (see D117011).

But it might indeed be better to not mark minf/maxf commutative.
Otherwise, we would likely need specify that all NaNs are 'same' (i.e. ignoring the payload).

If 'same' is IEEE equal, they are clearly not commutative for NaNs.
If 'same' is memcmp, the expansion in D117011 will not be valid.

I can't think of how +0/-0 would be special wrt to commutativity.