[all-commits] [llvm/llvm-project] 377f27: [X86] `DAGTypeLegalizer::ModifyToType()`: when wid...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 377f27be87f92e82902be277bb02c401475c9aa1
      https://github.com/llvm/llvm-project/commit/377f27be87f92e82902be277bb02c401475c9aa1
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2022-10-24 (Mon, 24 Oct 2022)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
    M llvm/test/CodeGen/X86/masked_gather_scatter.ll
    M llvm/test/CodeGen/X86/masked_store.ll
    M llvm/test/CodeGen/X86/pr45563-2.ll
    M llvm/test/CodeGen/X86/pr45833.ll

  Log Message:
  -----------
  [X86] `DAGTypeLegalizer::ModifyToType()`: when widening w/ zeros, insert into undef and `and`-mask the padding away

We can expect that the sequence of inserting-of-extracts-into-undef
will be successfully lowered back into widening of the source vector,
but it seems that at least for X86 mask vectors, we have a really hard time
recovering from inserting-into-zero.

I've looked into alternative fix injection points, and they are much more
involved, by the time of `LowerBUILD_VECTORvXi1()`/`LowerINSERT_VECTOR_ELT()`
the constants might be obscured, so it does not seem like we can easily
deal with this by lowering into bit math later on,
some other pieces are missing.

Instead, it seems like just clearing the padding away via an `AND`-mask
is at least not a worse choice. Why create a problem where there wasn't one.
Though yes, it is possible that there are cases where constants originate
from the source IR, so some other fix may still be needed.

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D136046