[PATCH] D79197: [SVE] Fix invalid usage of getNumElements() in InstCombineMulDivRem
Francesco Petrogalli via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 30 15:38:58 PDT 2020
fpetrogalli added a comment.
Hi @ctetreau ,
you say:
> getLogBase2 tries to walk its input vector type to do its work. This
> cannot be done for scalable vectors
I agree with you if we imagine the input scalable vector consisting of different powers of two, say `[2^c1, 2^c2, 2^c3, ...]`
I am thinking at the situation in which a scalable vector is the splat of a power of 2, say `[2^c, 2^c, ..., 2^c]`. I think in this case returning `nullptr` might lead to a missed optimization opportunity? For example, I have highlighted a place in the code where the power of 2 is used to simplify `udiv`. I think we want to have that optimization for scalable vectors too: surely we can retrieve the scalable vector "splat of C" from the scalable vector "splat of 2^C"?
Thank you for working on this!
Regards,
Francesco
================
Comment at: llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp:847-849
Constant *C1 = getLogBase2(Op0->getType(), cast<Constant>(Op1));
if (!C1)
llvm_unreachable("Failed to constant fold udiv -> logbase2");
----------------
Wouldn't your changes get to LLVM unreachable here? Would it make sense to have a test that checks that `X udiv Y` don't crash the compiler when both X and Y are scalable vector and Y is a splat of a power of 2?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79197/new/
https://reviews.llvm.org/D79197
More information about the llvm-commits
mailing list