[all-commits] [llvm/llvm-project] cb941f: [RISCV][SLP] Add tests for GEP costs

[Luke Lau via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cb941f9220d5e855f45cd25d1c2f12e3709536cc
      https://github.com/llvm/llvm-project/commit/cb941f9220d5e855f45cd25d1c2f12e3709536cc
  Author: Luke Lau <luke at igalia.com>
  Date:   2023-06-29 (Thu, 29 Jun 2023)

  Changed paths:
    A llvm/test/Analysis/CostModel/RISCV/gep-zero-indices.ll
    M llvm/test/Analysis/CostModel/RISCV/gep.ll

  Log Message:
  -----------
  [RISCV][SLP] Add tests for GEP costs

This patch updates the tests in gep.ll to have explicitly memory
accesses using them, to illustrate the new behaviour in D149889.
New tests have also been added for mismatched pointer types and memory
access types, and gep-zero-indices.ll has also been added to make sure
that we always cost GEPs with all zero indices as free.


  Commit: a68dcd09e8084dc179fb3218e8953417c4b7474a
      https://github.com/llvm/llvm-project/commit/a68dcd09e8084dc179fb3218e8953417c4b7474a
  Author: Luke Lau <luke at igalia.com>
  Date:   2023-06-29 (Thu, 29 Jun 2023)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
    M llvm/include/llvm/CodeGen/BasicTTIImpl.h
    M llvm/lib/Analysis/TargetTransformInfo.cpp
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp
    M llvm/lib/Target/X86/X86TargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
    M llvm/test/Analysis/CostModel/ARM/mve-gather-scatter-cost.ll
    M llvm/test/Analysis/CostModel/RISCV/gep.ll

  Log Message:
  -----------
  [TTI] Use users of GEP to guess access type in getGEPCost

Currently getGEPCost uses the target type of the GEP as a heuristic for
the type that will be accessed, to pass onto isLegalAddressingMode.
Targets use this to work out if a GEP can then be folded into the
load/store instruction that uses the GEP.
For example, on RISC-V loads and stores can have an offset added to a
base register folded into a single instruction, so the following GEP is
free:

%p = getelementptr i32, ptr %base, i32 42       ; getInstructionCost = 0
%x = load i32, ptr %p                           ; getInstructionCost = 1
------------------------------------------------------------------------
lw t0, a0(42)

However vector loads and stores cannot have an offset folded into them,
so the following GEP is costed:

%p = getelementptr <2 x i32>, ptr %base, i32 42 ; getInstructionCost = 1
%x = load <2 x i32>, ptr %p                     ; getInstructionCost = 1
------------------------------------------------------------------------
addi  a0, 42
vle32 v8, (a0)

The issue arises whenever there is a mismatch between the target type of
the GEP and the type that is actually accessed:

%p = getelementptr i32, ptr %base, i32 42       ; getInstructionCost = 0
%x = load <2 x i32>, ptr %p                     ; getInstructionCost = 1
------------------------------------------------------------------------
addi  a0, 42
vle32 v8, (a0)

Even though this GEP will result in an add instruction, because TTI
thinks it's loading an i32, it will think it can be folded and not
charge for it.

The target type can become mismatched with the memory access during
transformations, noticeably during SLP where a scalar base pointer will
be reused to perform a vector load or store.

This patch adds an optional AccessType argument to getGEPCost which
allows the type of memory accessed by users to be passed in as a hint,
so that we can more accurately determine if the GEP can be folded into
its users.

If AccessType is not provided, getGEPCost falls back to the old
behaviour of using the PointeeType to guess the memory access type. This
can be revisited in a later patch.

Also for now, only GEPs with exactly one user use the access type hint.
Whilst we could look through all users and use all access types to
determine if we can fold the GEP, this patch avoids doing so to prevent
O(N) behaviour.

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


Compare: https://github.com/llvm/llvm-project/compare/1f91fe3261c8...a68dcd09e808