[PATCH] D71389: [ConstantFold][SVE] Fix constant folding for bitcast.

Sander de Smalen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 13 03:03:13 PST 2019


sdesmalen added inline comments.


================
Comment at: llvm/lib/IR/ConstantFold.cpp:52
+  // compile-time.
+  if (DstTy->isScalable())
+    return nullptr;
----------------
efriedma wrote:
> spatel wrote:
> > spatel wrote:
> > > efriedma wrote:
> > > > huihuiz wrote:
> > > > > sdesmalen wrote:
> > > > > > Do we want to add support for a special case here for splat operations (like the one in the test)?
> > > > > Actually we can not, we will end up in scalable vector constant. 
> > > > > Instead of <4 x i32> <i32 1, i32 1, i32 1, i32 1>, we will need a form like "<vscale x 4 x i32> [?]"
> > > > > 
> > > > > I don't know how to express scalable vector constant in current upstream, please let me know if I get anything wrong?
> > > > I think the suggestion is to special-case the specific sequence of insertelement+splatvector+bitcast, and bitcast the operand of the insertelement.  Not sure how useful that would be in general, though.
> > > If we want to do that transform, it would go in instsimplify since we're doing a multi-instruction analysis/fold that becomes a constant.
> > Sorry - might've misread that. If we're creating a new bitcast, that would have to go in instcombine (we don't create new instructions in instsimplify).
> By the time we get here, the shuffle and insertelement are ConstantExprs, not instructions.
In terms of usefulness, this would make it easier to determine whether the value is a splat when calling `Constant::getSplatValue` without having to look through the bitcast first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71389





More information about the llvm-commits mailing list