-
Notifications
You must be signed in to change notification settings - Fork 304
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][LowerTypes] Keep the order of bundle fields in lowered cat
#6376
[FIRRTL][LowerTypes] Keep the order of bundle fields in lowered cat
#6376
Conversation
c16a2bb
to
3fb8ea7
Compare
This PR also reverses the current order of all bits extract, I'm not very sure if this is an acceptable change? (Will it break something?) |
@@ -1373,6 +1373,7 @@ bool TypeLoweringVisitor::visitExpr(BitCastOp op) { | |||
if (type_isa<BundleType, FVectorType>(op.getResult().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.
You need to change the direction based on types. We should keep the original order for Vector type.
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.
PR updated, looks like I just misunderstood something. Thanks.
3fb8ea7
to
7417fc5
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! It looks good to me but let me check this change internally to make sure 👍
auto isBundle = [](Type type) { | ||
if (auto refType = type_dyn_cast<RefType>(type)) | ||
type = refType.getType(); | ||
return type_isa<BundleType>(type); | ||
}; |
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.
You could use type_isa<BundleType>(getBaseType(type))
but is it possible for RefType to be an operand of BitCast op?
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.
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.
peelType
can be used for a wide range of operations but bitcast op doesn't take ref type as input. So you can drop the ref type handling.
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.
Makes sense, dropped it.
7417fc5
to
120e792
Compare
120e792
to
1539593
Compare
Gently ping @uenoku. Any updates on internal checks? Are there any further issues with this PR that need to be fixed? |
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 just realized, this fix would be good to merge. I did some testing, and this looks good. Approving and merging it now.
Fixes #6360.
The first fix #6339 (reverted) caused a regression reported in #6360.
In the first try, I forgot to handle the bit extract operation that follows it, the PR tries to fix it again without regression.
Credit: Thanks to @uenoku for the hint (#6360 (comment))