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>, .\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

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.

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.