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

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?



Regards,
Zeson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210916/615ae653/attachment.html>

Hi Zeson,

I've given this some thought recently. PowerPC, unlike RISCV64 has
different register classes for 32 and 64 and they have a full set of
instructions for both register classes. RV64 only has 64-bit
AND/OR/XOR/compares and the ABI requires 32-bit values to be passed sign
extended.

If we make i32 legal, then all values between basic blocks will be i32
instead of i64. We currently try to insert sext_inreg when we type legalize
so that we can make use of SelectionDAGBuilder's ability to propagate known
sign bits across basic blocks using AssertSExt nodes. If we start using i32
across basic blocks we lose this and will need a MachineIR pass to clean it
up. Granted we're not perfect today and maybe should have such a MachineIR
pass anyway.

I have thought about adopting the approach of Mips64 where i32 is legal but
the upper bits of the register are always sign extended. I believe their
32-bit instructions explicitly check this in hardware. This could simplify
some of the cross basic block issues because now everything is always sign
extended. It does require some tricky things like an i64->i32 truncate must
be emitted as a sext.w in order to enforce the sign extension rule. These
might be unnecessary depending what the using instructions are, but again
SelectionDAG's single basic block limitation makes this difficult to see.
So we would again probably need a MachineIR pass to do cleanup.

I don't know what the right answer is.

~Craig


On Thu, Sep 16, 2021 at 3:22 AM 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?
>
>
>
> Regards,
> Zeson
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210916/e2ff1530/attachment.html>

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