arith_ext: add lowering to arith operations #715
Conversation
inbelic
force-pushed
the
inbelic/lower-arith-ext
branch
from
3d3aa7c
to
bf95bb5
Compare
inbelic
force-pushed
the
inbelic/lower-arith-ext
branch
from
bf95bb5
to
ebbbcef
Compare
j2kun
added
the
pull_ready
|
|
||
| // Using DRR to generate the lowering patterns for specific operations | ||
|
|
||
| defvar DefGE = ConstantEnumCase<Arith_CmpIPredicateAttr, "uge">; |
There was a problem hiding this comment.
I wonder if we will always want this to be unsigned (uge = unsigned greater equal) vs signed. I feel that perhaps we should all agree on the semantics of arith_ext ops on this front, i.e., that we always take the representative in [0, modulus) for modular operations.
Still happy to submit and revisit this later.
There was a problem hiding this comment.
I agree we should discuss this further.
I think if we let it be signed then we will have similar confusion/issue with using RemSI where it treats both operands as signed and we generally don't want the second operand to be signed.
FWIW, in the context of HEaan, they do make the assumption that it is an unsigned input.
There was a problem hiding this comment.
I was planning to spend some time in the next meeting on discussing how we model modular arithmetic, and data-type semantics in general, and I think the signedness question would be a good addition to the list :)
Following up on #711