[all-commits] [llvm/llvm-project] e261f2: [RISCV] Add TSFlag for reading past VL behaviour. ...

[Luke Lau via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e261f2895f158632ca279f6e63bd2b9aa6ef7846
      https://github.com/llvm/llvm-project/commit/e261f2895f158632ca279f6e63bd2b9aa6ef7846
  Author: Luke Lau <luke at igalia.com>
  Date:   2025-08-15 (Fri, 15 Aug 2025)

  Changed paths:
    M llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
    M llvm/lib/Target/RISCV/RISCVInstrFormats.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoV.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoXRivos.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoXSf.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoXSfmm.td
    M llvm/lib/Target/RISCV/RISCVVLOptimizer.cpp

  Log Message:
  -----------
  [RISCV] Add TSFlag for reading past VL behaviour. NFCI (#149704)

Currently we have a switch statement that checks if a vector instruction
may read elements past VL. However it currently doesn't account for
instructions in vendor extensions.

Handling all possible vendor instructions will result in quite a lot of
opcodes being added, so I've created a new TSFlag that we can declare in
TableGen, and added it to the existing instruction definitions.

I've tried to be conservative as possible here: All SiFive vendor vector
instructions should be covered by the flag, as well as all of
XRivosVizip, and ri.vextract from XRivosVisni.

For now this should be NFC because coincidentally, these instructions
aren't handled in getOperandInfo, so RISCVVLOptimizer should currently
avoid touching them despite them being liberally handled in
getMinimumVLForUser.

However in an upcoming patch we'll need to also bail in
getMinimumVLForUser, so this prepares for it.



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