[llvm-dev] What's SEXT_INREG and why DAGCombiner is producing it?

[Jason Eckhardt via 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>