[llvm-dev] [SelectionDAG][RISCV] i32 type illegal in 64-bit target is really a good design in RISCV?

[Zeson via llvm-dev]

Hi, Alex.

I think what you mentioned is XLenVT functional infra that avoids the duplication of the same non-W instruction for RV32 and RV64. Could it be possible to keep XLenVT infra for non-W instruction to make it only one definition for both RV32 and RV64, and also one W instruction definition which only for RV64?

Regards,
Zeson
------------------------------------------------------------------
Sender:Alex Bradbury <asb at asbradbury.org>
Sent At:2021 Sep. 20 (Mon.) 22:01
Recipient:Zeson <zixuan.wu at linux.alibaba.com>
Cc:llvm-dev <llvm-dev at lists.llvm.org>
Subject:Re: [llvm-dev] [SelectionDAG][RISCV] i32 type illegal in 64-bit target is really a good design in RISCV?

On Thu, 16 Sept 2021 at 11:22, Zeson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi, all.
>
> Considering the issue to leverage i32 series instructions, https://reviews.llvm.org/D107658. Also some other target DAG combine actions such as combining any_ext node to leverage ADDW/SUBW/...
> I think those effects are caused by originally and naturally treating i32 type illegal in 64-bit target for RISCV. And it makes much following work to add patches.
> Is it really a good way to handle i32 type in 64-bit mode RISCV target?
> Could it be just like what PowerPC does that make both i32 and i64 are legal in DAG selection phase?

Hi Zeson,

It's definitely a pain point for the RISC-V backend, though I would
highlight that making i32 a legal type and therefore duplicating all
instruction definitions for RV32 and RV64 has its own drawbacks
(repetition, possibility of surprising codegen differences for 32 vs
64-bit due to missing the duplicated instructions in instruction
patterns or elsewhere in the backend). You could of course argue that
those issues may be easier to debug and reason about than some of the
hassles with *W instructions.

Please see <https://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>
for the initial RFC and discussion on this.

I think ideally we would be able to maintain a single set of
parameterised instruction definitions (and I'd be keen to discuss any
ideas on making this easier to work with), but obviously if the
current implementation approach is causing more problems than it
solves we should be pragmatic.

Best,

Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210922/c3aa2675/attachment.html>