[PATCH] D68739: [GISel] Allow ConstantFoldBinOp to consider G_FCONSTANT binary representation for combines

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 9 16:03:28 PDT 2019


arsenm added inline comments.


================
Comment at: llvm/lib/CodeGen/GlobalISel/Utils.cpp:323-325
+      (&FPVal->getValueAPF().getSemantics() == &APFloat::IEEEdouble() ||
+       &FPVal->getValueAPF().getSemantics() == &APFloat::IEEEsingle() ||
+       &FPVal->getValueAPF().getSemantics() == &APFloat::IEEEhalf())) {
----------------
kariddi wrote:
> kariddi wrote:
> > arsenm wrote:
> > > Why do you need to whitelist these types?
> > Are the types that fit a uint64 that we know of, but I guess that could be checked from "the only user" of this function instead
> Actually, that's not necessarily true ... ConstantFoldBinOp used to use a function that only handled Optional<int64_t> . Now I substituted that with a function that returns APInt (for simplicity), but I wanted to keep the functionality the same as getConstantVRegVal() I guess ...
> 
> I guess I can remove that limitation for the Floats, but maintain the limitation fo the integers and then check in ConstantFoldBinOp.
> 
> I'm just scared that allowing ConstantFoldBinOp to digest things it never saw before would cause some "unexpected consequence" :-P
I'm worried about somebody adding bfloat16 or something and then never updating this list. I think it would be fine to just return anything bitcastToAPInt will handle


Repository:
  rL LLVM

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

https://reviews.llvm.org/D68739





More information about the llvm-commits mailing list