[PATCH] D126794: [RISCV] Lower VLEFF/VLSEGFF SDNodes to MachineInstrs with VL outputs.
Yeting Kuo via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 3 03:32:07 PDT 2022
fakepaper56 added inline comments.
================
Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h:176
+/// \returns true if there is a VL output for the instruction.
+static inline bool hasVLOutput(uint64_t TSFlags) {
+ return TSFlags & HasVLOutputMask;
----------------
reames wrote:
> Not sure how much value we have here from having the generic bit field for this over a static method which switches on the opcodes. This really only applies to the FF variants.
How about use `getNumExplicitDefs() == 2` to check whether a MI is VLEFF/VLSEGFF?
================
Comment at: llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp:1438
+ MachineInstrBuilder MIB =
+ BuildMI(MBB, I, DL, TII->get(NewOpc), MI.getOperand(0).getReg());
+ unsigned Cur = 2;
----------------
craig.topper wrote:
> reames wrote:
> > Did you play with what happens if you just set the second destination register to VL?
> >
> > If that works, then we'd avoid the need for the second set of pseudos. Not sure it does, but maybe?
> The register class wouldn't match, so I doubt it would work.
>
> Might be able to use an OptionalDef though?
Just replacing `CurDAG->getRegister(RISCV::VL, Subtarget->getXLenVT())` with ReadVL causes ICE about legalization. I don't really understand OptionalDef yet, but I have some questions about the method.
First, the method seems to break the SSA form of VL and we need to know which modifies the VL right?
Second, Is possible that the use of VL be moved behind the VLEFF/VLSEGFF MI?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126794/new/
https://reviews.llvm.org/D126794
More information about the llvm-commits
mailing list