This is an archive of the discontinued LLVM Phabricator instance.

ConstantFolding: Constant fold some canonicalizes
ClosedPublic

Authored by arsenm on Nov 11 2022, 11:38 AM.

Details

Summary

+/-0 is obviously foldable. Other non-special, non-subnormal
values are also probably OK. For denormal values, check
the calling function's denormal mode. For now, don't fold
denormals to the input for IEEE mode because as far as I know
the langref is still pretending LLVM's float isn't IEEE.

Also folds undef to 0, although NaN may make more sense. Skips
folding nans and infinities, although it should be OK to fold those
in a future change.

Diff Detail

Event Timeline

arsenm created this revision.Nov 11 2022, 11:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2022, 11:38 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
arsenm requested review of this revision.Nov 11 2022, 11:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2022, 11:38 AM
Herald added a subscriber: wdng. · View Herald Transcript

I don't have any real-world experience with canonicalize, but this seems fine. What happens with poison? (add a test for that)

arsenm updated this revision to Diff 476201.Nov 17 2022, 11:54 AM
arsenm added a reviewer: jcranmer-intel.

Rebase on a bunch more baseline tests. Handle infinities, poison->poison instead of 0. Skip the exotic FP types since I don't understand them

spatel accepted this revision.Nov 18 2022, 7:30 AM

LGTM - see inline for code comment updates.

llvm/include/llvm/IR/Type.h
183

This comment ("six") hasn't aged well - I'd just delete it.

llvm/lib/Analysis/ConstantFolding.cpp
1948

Delete the "I sure hope" - if we're coding it this way, it's the law. If there's fallout, it'll change. :)

This revision is now accepted and ready to land.Nov 18 2022, 7:30 AM
llvm/include/llvm/IR/Type.h
167–170

I'm not sure I like the name "IEEELike", but, admittedly, I'm struggling to keep up with anything better (as bfloat isn't an IEEE type at all, and x86_fp80 is an IEEE extended precision format).

The documentation comment should clarify that it's referring to APFloat::isIEEE(). I think "does not have unnormal values" can be clarified as "does not have non-IEEE values, such as x86_fp80's unnormal values".

llvm/lib/Analysis/ConstantFolding.cpp
1948

If I'm reading the source code of APFloat, and of glibc, correctly, then APFloat considers {0.0, *} to be isZero() for ppc_fp128, which shouldn't be considered a canonical value.

You should be fine for x86_fp80.

1966

Denormal in IEEE denormal mode should be canonical, right? Or are you using this mode to assume "it's dynamic, so we don't know if it's canonical or not" (in which case, add a comment to this effect)?

arsenm added inline comments.Nov 18 2022, 12:34 PM
llvm/lib/Analysis/ConstantFolding.cpp
1966

Yes. This isn't a strictfp intrinsic, so it's not considering the dynamic mode at all.

I think this should fold the denormal, but if anything is going to break, it would be this. I was mostly worried about things like x87 unnormal values, but now it's just not touching those. I'll probably post a follow up patch to fold here in the future

arsenm added inline comments.Nov 18 2022, 2:59 PM
llvm/lib/Analysis/ConstantFolding.cpp
1948