-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lattigo: Add Negate op and e2e CMUX example #1627
Lattigo: Add Negate op and e2e CMUX example #1627
Conversation
9fd8287
to
e64986e
Compare
Rebased after #1620 is in. Ready for review now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Very small nits
valueString = "[]int64{"; | ||
for (auto value : denseAttr.getValues<APInt>()) { | ||
valueString += std::to_string(value.getSExtValue()) + ", "; | ||
if (denseAttr.getType().getElementType().isInteger(1)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: i was noticing the i1 / bool case isn't handled for the IntegerAttr case above, but then in convertType it is handlded below.
Maybe you can remove this typeswitch and instead rely on auto res = convertType(valueAttr.getType())
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now arith.constant
is honest on type: what is in IR is converted to corresponding type using convertType. The reason int64/float64 is deliberately here was that Encode/Decode only accepts int64[]/float64[]
and we have the following common pattern
cst = arith.constant <4xi16>
Decode(pt, cst)
so for convenience I directly convert i16 to i64. Now the extra step is done in DecodeOp.
bfdefac
to
7398502
Compare
7398502
to
f7ca8da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks as always!
It looks like this is failing the cmux test at head
This was internal so I will try to reproduce externally
|
Is this the same problem as #1671 |
Confirmed. Here's the trace:
|
ok I will remove my smoke test from that PR so it can go in on its own |
Cherry-picking #1671 indeed fixes the issue. |
Do I need to rebase this (how is the internal patching status for it) (changes in #1661 also apply here so there will be some new change if I rebase) |
I am syncing the internal patch now, will let you know. |
Looks like the patch is working, and should land shortly |
Fixes #1623
Depends on #1620.
This PR construct a Lattigo Negate Op via ring operation in Lattigo (they seem not to offer a high level one).
To better demonstrate its use a CMUX e2e example from #1620 is also added.