[all-commits] [llvm/llvm-project] 2c9e9f: [SCCP] Handle llvm.experimental.get.vector.length ...

[Luke Lau via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2c9e9ffa77e37fa0ff5d15325dab5471636b8a44
      https://github.com/llvm/llvm-project/commit/2c9e9ffa77e37fa0ff5d15325dab5471636b8a44
  Author: Luke Lau <luke at igalia.com>
  Date:   2025-12-01 (Mon, 01 Dec 2025)

  Changed paths:
    M llvm/lib/Transforms/Utils/SCCPSolver.cpp
    A llvm/test/Transforms/SCCP/get_vector_length-intrinsic.ll

  Log Message:
  -----------
  [SCCP] Handle llvm.experimental.get.vector.length calls (#169527)

As noted in the reproducer provided in
https://github.com/llvm/llvm-project/issues/164762#issuecomment-3554719231,
on RISC-V after LTO we sometimes have trip counts exposed to vectorized
loops. The loop vectorizer will have generated calls to
@llvm.experimental.get.vector.length, but there are [some
properties](https://llvm.org/docs/LangRef.html#id2399) about the
intrinsic we can use to simplify it:

- The result is always less than both Count and MaxLanes
- If Count <= MaxLanes, then the result is Count

This teaches SCCP to handle these cases with the intrinsic, which allows
some single-iteration-after-LTO loops to be unfolded.

#169293 is related and also simplifies the intrinsic in InstCombine via
computeKnownBits, but it can't fully remove the loop since
computeKnownBits only does limited reasoning on recurrences.



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