[all-commits] [llvm/llvm-project] db782b: [RISCV] Don't forward AVL in VSETVLIInfo if it wou...

[Luke Lau via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: db782b44b3471c0ab41950c3f79d0ea7b916c135
      https://github.com/llvm/llvm-project/commit/db782b44b3471c0ab41950c3f79d0ea7b916c135
  Author: Luke Lau <luke at igalia.com>
  Date:   2024-07-05 (Fri, 05 Jul 2024)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
    M llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.ll
    M llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir
    M llvm/test/Transforms/LoopStrengthReduce/RISCV/lsr-drop-solution.ll

  Log Message:
  -----------
  [RISCV] Don't forward AVL in VSETVLIInfo if it would clobber other definitions (#97264)

This fixes a crash found when compiling OpenBLAS with -mllvm
-verify-machineinstrs.

When we "forward" the AVL from the output of a vsetvli, we might have to
extend the LiveInterval of the AVL to where insert the new vsetvli.

Most of the time we are able to extend the LiveInterval because there's
only one val num (definition) for the register. But PHI elimination can
assign multiple values to the same register, in which case we end up
clobbering a different val num when extending:

    %x = PseudoVSETVLI %avl, ...
    %avl = ADDI ...
    %v = PseudoVADD ..., avl=%x
    ; %avl is forwarded to PseudoVADD:
    %x = PseudoVSETVLI %avl, ...
    %avl = ADDI ...
    %v = PseudoVADD ..., avl=%avl

Here there's no way to extend the %avl from the vsetvli since %avl is
redefined, i.e. we have two val nums.

This fixes it by only forwarding it when we have exactly one val num,
where it should be safe to extend it.



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