This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Standard] Add unsigned integers to UIToFPOp and FPToUIOp cast-compatibility checks
AbandonedPublic

Authored by NatashaKnk on May 26 2021, 5:09 PM.

Details

Reviewers
rriddle
Summary

Added support for unsigned int in addition to the already-existing signless int

Diff Detail

Event Timeline

NatashaKnk created this revision.May 26 2021, 5:09 PM
NatashaKnk requested review of this revision.May 26 2021, 5:09 PM
rriddle requested changes to this revision.May 26 2021, 5:22 PM

Standard operations are explicitly signless by design, i.e. they purposefully don't support signed/unsigned integers.

https://mlir.llvm.org/docs/Rationale/Rationale/#integer-signedness-semantics

This revision now requires changes to proceed.May 26 2021, 5:22 PM

I might be misunderstanding the situation, but if the Ops are signless why does SIToFOp exist? If we handle the explicitly signed case, why not the explicitly unsigned one?

I might be misunderstanding the situation, but if the Ops are signless why does SIToFOp exist?

When you design operations like this on Integer, you need to decide if you encode the sign in the type or in the operation name. For example you can have:

%uquotient = div %ua, %ub : uint32
%squotient = div %sa, %sb : sint32

where you decide to encode the sign in the type itself. In this case you only need one div operation. The alternative is to have a "signless" type for integer and encode the difference in the operation:

%squotient = sdiv %sa, %sb : int32
%uquotient = udiv %ua, %ub : int32

This last solution is what is preferred in the standard dialect. This is consistent with the existence of SIToFOp and UIToFOp: the sign aspect is carried by the operation and not by the type.

NatashaKnk abandoned this revision.May 27 2021, 12:18 PM

Oh, I completely missed that SItoFOp also checks for it to be signless, not signed. This makes sense. Thank you!