[all-commits] [llvm/llvm-project] 2d046b: [LSR] Improve the recognition of vscale immediates...

[Benjamin Maxwell via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2d046bd62066067a1de8cb65752f1dd9404c4121
      https://github.com/llvm/llvm-project/commit/2d046bd62066067a1de8cb65752f1dd9404c4121
  Author: Benjamin Maxwell <benjamin.maxwell at arm.com>
  Date:   2026-05-29 (Fri, 29 May 2026)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
    M llvm/test/Transforms/LoopStrengthReduce/AArch64/vscale-fixups.ll
    A llvm/test/Transforms/LoopStrengthReduce/AArch64/vscale-negative-i32-offset.ll

  Log Message:
  -----------
  [LSR] Improve the recognition of vscale immediates (#196998)

Previously, the extraction of vscale immediates was handled the same as
the non-scalable case. That is we'd look for a `vscale * constant`
scMulExpr on the LHS of the SCEV expression.

However, within a SCEV expression operands are ordered by "complexity",
which is defined (mostly) by the order of the SCEVTypes enum:
https://github.com/llvm/llvm-project/blob/bcb84e234980ca42ee47e21e4c97180c788c946a/llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h#L38-L59

So, (non-scalable) constants would always occur on the LHS as the
simplest expression type, but a scMulExpr could occur later in the
operand list for a scAddExpr (e.g., after a sext/zext expression). This
meant in some cases we'd fail to find vscale immediates.

This patch updates `ExtractImmediate` to search later operands to find
vscale offsets, and prefer vscale offsets based on the access type and
current BaseOffset. So for scalable accesses, we prefer finding vscale
immediates over fixed immediates when both are present.



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