[all-commits] [llvm/llvm-project] 530124: [X86] Don't drop a redundant 32-bit `and` whose us...

[Akash Manna via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5301245b7d20fc4871a3253fd235a31e69f1bdfb
      https://github.com/llvm/llvm-project/commit/5301245b7d20fc4871a3253fd235a31e69f1bdfb
  Author: Akash Manna <akash.manna.mymail at gmail.com>
  Date:   2026-09-21 (Mon, 21 Sep 2026)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
    M llvm/lib/Target/X86/X86InstrFragments.td
    A llvm/test/CodeGen/X86/pr222714.ll

  Log Message:
  -----------
  [X86] Don't drop a redundant 32-bit `and` whose users were selected as def32 (#223750)

Fixes #222714

Nothing was wrong with the IR or the DAG combines here; the `and %idx,
1` survived all the way into instruction selection. Isel selects users
before operands, so the `zext` of the (narrowed, i32) `and` had already
been turned into a `SUBREG_TO_REG` through the `def32` pattern, which
assumes the i32 producer zeroes the upper 32 bits. When isel then
reached the `and`, `shrinkAndImmediate` noticed via known bits that the
mask was redundant and replaced the `and` with its operand — a
`truncate` of a 64-bit `cmov`. That truncate is just a subregister copy,
so the already-emitted `SUBREG_TO_REG` ended up reading the whole 64-bit
register, and the upper bits went straight into the scaled address. The
`_BitInt(98)` is a red herring; the same thing happens with plain `i64`.

The `def32` predicate now lives in `X86DAGToDAGISel::isDef32` (the
PatLeaf calls it), and `shrinkAndImmediate` only drops a 32-bit `and`
when its operand satisfies that predicate. Otherwise it returns false
and the `and` is selected as a normal 32-bit instruction, which zeroes
the upper half as the users expect.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications