llvm dev - Dec 2021 - What's SEXT_INREG and why DAGCombiner is producing it?

Hi:
In my toy compiler backend, I currently don't / won't support
SEXT_IN_REG, mostly due to the lack of documentation explains its difference
between the "normal" sext.


However, when compiling a test program, I notice the following messaging emitted
by llc, despite already called ``setOperationType() to Expand``:


```
Combining: t41: i32 = sra t40, Constant:i64<31&gt;,
.\examples\crc.c:72:12
Creating new node: t44: i32 = sign_extend_inreg t2, ValueType:ch:i1,
.\examples\crc.c:72:12
&nbsp;... into: t44: i32 = sign_extend_inreg t2, ValueType:ch:i1,
.\examples\crc.c:72:12

```


I was under the impression the setOperationType(....EXPAND) call should instruct
the ISel System to expand this DAG Node?
Another question would be, what's the correct semantic for SEXT_IN_REG? Can
I just &nbsp;implement it as SExt?




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

On Fri, 3 Dec 2021 at 04:07, Zhang via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> In my toy compiler backend, I currently don't / won't support
SEXT_IN_REG, mostly due to the lack of documentation explains its difference
between the "normal" sext.
It's necessary/beneficial for sign extensions in types that aren't
legal on the target. For example most RISC backends have i32 and maybe
i64 as legal, so there's no other single-instruction way to represent
sign extensions from i8 or i16 (zero extension can be mapped to an
AND, though even it has a vector inreg form).
> However, when compiling a test program, I notice the following messaging
emitted by llc, despite already called ``setOperationType() to Expand``:
The code seems to be in DAGCombiner.cpp line7518 (in visitSRA). It
looks like it checks legality to me, but in an early phase (before
legalization) might produce it anyway expecting it to be further
lowered later.
> Another question would be, what's the correct semantic for SEXT_IN_REG?
Can I just  implement it as SExt?
Yes, it's just just a normal sign extend operation.

Cheers.

Tim.
>
>
> Zhang
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

In addition to what Tim stated, if you actually do need to expand
SIGN_EXTEND_INREG in SDISel,
you might try structuring your target lowering like this (e.g., on a typical
32-bit ISA):
  setOperationAction(ISD::SIGN_EXTEND_INREG, MVT::i16, Expand);
  setOperationAction(ISD::SIGN_EXTEND_INREG, MVT::i8 , Expand);
  setOperationAction(ISD::SIGN_EXTEND_INREG, MVT::i1 , Expand);
It wasn't clear from your prose ("setOperationType() to Expand")
how you actually set up your TLI.


________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Zhang via
llvm-dev <llvm-dev at lists.llvm.org>
Sent: Thursday, December 2, 2021 10:07 PM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] What's SEXT_INREG and why DAGCombiner is producing it?

External email: Use caution opening links or attachments

Hi:
In my toy compiler backend, I currently don't / won't support
SEXT_IN_REG, mostly due to the lack of documentation explains its difference
between the "normal" sext.

However, when compiling a test program, I notice the following messaging emitted
by llc, despite already called ``setOperationType() to Expand``:

```
Combining: t41: i32 = sra t40, Constant:i64<31>, .\examples\crc.c:72:12
Creating new node: t44: i32 = sign_extend_inreg t2, ValueType:ch:i1,
.\examples\crc.c:72:12
 ... into: t44: i32 = sign_extend_inreg t2, ValueType:ch:i1,
.\examples\crc.c:72:12
```

I was under the impression the setOperationType(....EXPAND) call should instruct
the ISel System to expand this DAG Node?
Another question would be, what's the correct semantic for SEXT_IN_REG? Can
I just  implement it as SExt?


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