Skip to content
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] LowerToHW: guard against folded operations #7358

Merged
merged 1 commit into from
Jul 19, 2024

Conversation

youngar
Copy link
Member

@youngar youngar commented Jul 19, 2024

In LowerToHW we copy the name from FIRRTL ops to the lowered HW ops. We often call createOrFold when creating the HW ops, which can mean that there is no operation to copy the name to. We were not properly detecting this scenario, which could cause us to try to copy the name to a null operation. Most ops were already covered under a guard in a generic code path, but div-like and subaccess-like operations needed to be guarded. Some of these problem are impossible to test right now as we require folders to be implemented for some operations.

@youngar youngar added the FIRRTL Involving the `firrtl` dialect label Jul 19, 2024
Copy link
Member

@seldridge seldridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@youngar youngar force-pushed the firrtl-lowering-bug branch 4 times, most recently from 0ee6ad3 to ee34bc1 Compare July 19, 2024 22:29
@@ -2752,7 +2753,8 @@ FailureOr<Value> FIRRTLLowering::lowerSubaccess(SubaccessOp op, Value input) {
result = builder.createOrFold<sv::ArrayIndexInOutOp>(input, valueIdx);
else
result = createArrayIndexing(input, valueIdx);
tryCopyName(result.getDefiningOp(), op);
if (auto definingOp = result.getDefiningOp())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR is missing one auto *definingOp in the cleanup.

In LowerToHW we copy the name from FIRRTL ops to the lowered HW ops.  We
often call `createOrFold` when creating the HW ops, which can mean that
there is no operation to copy the name to.  We were not properly
detecting this scenario, which could cause us to try to copy the name to
a null operation.  Most ops were already covered under a guard in a
generic code path, but div-like and subaccess-like operations needed to
be guarded.  Some of these problem are impossible to test right now as
we require folders to be implemented for some operations.
@youngar youngar merged commit fdcf481 into llvm:main Jul 19, 2024
4 checks passed
@youngar youngar deleted the firrtl-lowering-bug branch July 19, 2024 23:06
dtzSiFive pushed a commit that referenced this pull request Sep 6, 2024
In LowerToHW we copy the name from FIRRTL ops to the lowered HW ops.  We
often call `createOrFold` when creating the HW ops, which can mean that
there is no operation to copy the name to.  We were not properly
detecting this scenario, which could cause us to try to copy the name to
a null operation.  Most ops were already covered under a guard in a
generic code path, but div-like and subaccess-like operations needed to
be guarded.  Some of these problems are impossible to test right now as
we require folders to be implemented for some operations.
dtzSiFive pushed a commit to dtzSiFive/circt that referenced this pull request Sep 6, 2024
In LowerToHW we copy the name from FIRRTL ops to the lowered HW ops.  We
often call `createOrFold` when creating the HW ops, which can mean that
there is no operation to copy the name to.  We were not properly
detecting this scenario, which could cause us to try to copy the name to
a null operation.  Most ops were already covered under a guard in a
generic code path, but div-like and subaccess-like operations needed to
be guarded.  Some of these problems are impossible to test right now as
we require folders to be implemented for some operations.
dtzSiFive added a commit that referenced this pull request Sep 6, 2024
In LowerToHW we copy the name from FIRRTL ops to the lowered HW ops.  We
often call `createOrFold` when creating the HW ops, which can mean that
there is no operation to copy the name to.  We were not properly
detecting this scenario, which could cause us to try to copy the name to
a null operation.  Most ops were already covered under a guard in a
generic code path, but div-like and subaccess-like operations needed to
be guarded.  Some of these problems are impossible to test right now as
we require folders to be implemented for some operations.

This backports #7358 to 1.62.0 for Chisel 6 users.

Co-authored-by: Andrew Young <youngar17@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FIRRTL Involving the `firrtl` dialect
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants