-
Notifications
You must be signed in to change notification settings - Fork 277
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
[FIRRTL] Canonicalize away CVT and adjust all patterns which matched cvt #5527
Conversation
Co-authored-by: Fabian Schuiki <fabian@schuiki.ch>
…dev/darthscsi/castcanon
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 for the quick fix.
Can you include the test that triggered this?
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, can we add the regression tests this fixes?
Looks nicer too, and that EqualIntSize
was something I was reaching for earlier, thanks for adding!
This looks right but didn't deep dive it.
(AndPrimOp $x, (NativeCodeCall<"$_builder.create<ConstantOp>($0.getLoc(), cast<IntType>($0.getType()), $1.getValue().trunc($1.getValue().getBitWidth()-1).zext(*cast<IntType>($0.getType()).getWidth()))"> $x, $cst)) | ||
(AndPrimOp $x, (NativeCodeCall<"$_builder.create<ConstantOp>($0.getLoc(), " | ||
"cast<IntType>($0.getType()), " | ||
"$1.getValue().sextOrTrunc(cast<IntType>($0.getType()).getWidthOrSentinel()))"> $x, $cst)) |
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.
🤔 could this pattern work for non-constants (of known width) equally well, and let a different folder create the sextortrunc
thing for us?
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.
(This can be done separately, partly just curious, it's of course more important to fix the issue, thanks!)
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.
I was playing with a conversion via asSInt and then a width-narrowing pattern.
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.
We have more robust width-narrowing in comb, and I'm inclined to do more of this stuff in comb where it's less error prone.
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.
Not validated in excruciating detail. Looks fine, though.
def CVTUnSigned : Pat< | ||
(CvtPrimOp:$old $x), | ||
(MoveNameHint $old, | ||
(AsSIntPrimOp | ||
(CatPrimOp | ||
(NativeCodeCall<"$_builder.create<ConstantOp>($0.getLoc(), APSInt(APInt()))"> $old), | ||
$x))), | ||
[(UIntType $x)]>; |
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.
This canonicalization effectively removes the need for cvt
. Maybe we just boot this from the spec or remove this during parsing and drop the operation.
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.
CVT primarily exists for inferred widths. It may be convenient in that context (e.g. at chisel emission), but I'm not sure.
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.
LGTM
closes #5524