[all-commits] [llvm/llvm-project] db231e: [InstCombine] fold fake vector extract to shift+trunc
RotateRight via All-commits
all-commits at lists.llvm.org
Wed Oct 6 05:13:57 PDT 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: db231ebdb07f38f8b5d92311a4dc89e63c5a9d05
https://github.com/llvm/llvm-project/commit/db231ebdb07f38f8b5d92311a4dc89e63c5a9d05
Author: Sanjay Patel <spatel at rotateright.com>
Date: 2021-10-06 (Wed, 06 Oct 2021)
Changed paths:
M llvm/lib/Transforms/InstCombine/InstCombineInternal.h
M llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
M llvm/test/Transforms/InstCombine/X86/x86-avx512-inseltpoison.ll
M llvm/test/Transforms/InstCombine/X86/x86-avx512.ll
M llvm/test/Transforms/InstCombine/extractelement.ll
Log Message:
-----------
[InstCombine] fold fake vector extract to shift+trunc
We already handle more complicated cases like:
extelt (bitcast (inselt poison, X, 0)) --> trunc (lshr X)
But we missed this simpler pattern:
https://alive2.llvm.org/ce/z/D55h64 / https://alive2.llvm.org/ce/z/GKzzRq
This is part of solving:
https://llvm.org/PR52057
I made the transform depend on legal/desirable int type to avoid creating
a shift of an illegal type (for example i128). I'm not sure if that
restriction is actually necessary, but we can change that as a follow-up
if the backend can deal with integer ops on too-wide illegal types.
The pile of AVX512 test changes are all neutral AFAICT - the x86 backend
seems to know how to turn that into the expected "kmov" instructions.
Differential Revision: https://reviews.llvm.org/D111082
More information about the All-commits
mailing list