[all-commits] [llvm/llvm-project] 12a499: Pre-commit test case for trunc+lshr+load folds

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 12a499eb00e36bb0944c6b1f7f8721fd90a5bd8f
      https://github.com/llvm/llvm-project/commit/12a499eb00e36bb0944c6b1f7f8721fd90a5bd8f
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2022-01-24 (Mon, 24 Jan 2022)

  Changed paths:
    M llvm/test/CodeGen/X86/shift-folding.ll

  Log Message:
  -----------
  Pre-commit test case for trunc+lshr+load folds

This is a pre-commit of test cases relevant for D117406.

@srl_load_narrowing1 is showing a pattern that could be folded into
a more narrow load.

@srl_load_narrowing2 is showing a similar pattern that happens to
be optimized already, but that happens in two steps (first triggering
a combine based on SRL and later another combine based on TRUNCATE).

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


  Commit: 46cacdbb21c221a4304c489cb4a1abbc51967bb1
      https://github.com/llvm/llvm-project/commit/46cacdbb21c221a4304c489cb4a1abbc51967bb1
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2022-01-24 (Mon, 24 Jan 2022)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
    M llvm/test/CodeGen/ARM/shift-combine.ll
    M llvm/test/CodeGen/X86/shift-folding.ll

  Log Message:
  -----------
  [DAGCombiner] Adjust some checks in DAGCombiner::reduceLoadWidth

In code review for D117104 two slightly weird checks were found
in DAGCombiner::reduceLoadWidth. They were typically checking
if BitsA was a mulitple of BitsB by looking at (BitsA & (BitsB - 1)),
but such a comparison actually only make sense if BitsB is a power
of two.

The checks were related to the code that attempted to shrink a load
based on the fact that the loaded value would be right shifted.

Afaict the legality of the value types is checked later (typically in
isLegalNarrowLdSt), so the existing checks were both overly
conservative as well as being wrong whenever ExtVTBits wasn't a
power of two. The latter was a situation triggered by a number of
lit tests so we could not just assert on ExtVTBIts being a power of
two).

When attempting to simply remove the checks I found some problems,
that seems to have been guarded by the checks (maybe just out of
luck). A typical example would be a pattern like this:

  t1 = load i96* ptr
  t2 = srl t1, 64
  t3 = truncate t2 to i64

When DAGCombine is visiting the truncate reduceLoadWidth is called
attempting to narrow the load to 64 bits (ExtVT := MVT::i64). Then
the SRL is detected and we set ShAmt to 64.

In the past we've bailed out due to i96 not being a multiple of 64.
If we simply remove that check then we would end up replacing the
load with a new load that would read 64 bits but with a base pointer
adjusted by 64 bits. So we would read 32 bits the wasn't accessed by
the original load.
This patch will instead utilize the fact that the logical left shift
can be folded away by using a zextload. Thus, the pattern above will
now be combined into

  t3 = load i32* ptr+offset, zext to i64


Another case is shown in the X86/shift-folding.ll test case:

  t1 = load i32* ptr
  t2 = srl i32 t1, 8
  t3 = truncate t2 to i16

In the past we bailed out due to the shift count (8) not being a
multiple of 16. Now the narrowing kicks in and we get

  t3 = load i16* ptr+offset

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


Compare: https://github.com/llvm/llvm-project/compare/3e6be0241b31...46cacdbb21c2