Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[FIRRTL] Add back unambiguous path requirement. #7588

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Sep 5, 2024
Merged

[FIRRTL] Add back unambiguous path requirement. #7588

merged 1 commit into from
Sep 5, 2024

Conversation

@mikeurbach
Copy link
Contributor

This was made a warning in #7129. In reality, the flows can fail during LowerClasses if we do allow this through, so this adds back the previous restrictions so we ensure from the start that we have unambiguous paths as originally intended.

Closes #7128.

@mikeurbach
[FIRRTL] Add back unambiguous path requirement.
6dbacb0 
This was made a warning in #7129. In
reality, the flows can fail during LowerClasses if we do allow this
through, so this adds back the previous restrictions so we ensure from
the start that we have unambiguous paths as originally intended.

Closes #7128.
dtzSiFive
dtzSiFive approved these changes Sep 5, 2024
View reviewed changes
Copy link
Contributor

@dtzSiFive dtzSiFive left a comment

Choose a reason for hiding this comment

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

LGTM!

Is it possible these nodes are the top-levels such that they don't have one use but also aren't problematically multiply-instantiated?

I think that's not a thing but just asking the defensive question in case it's clear it might 👍 .

@mikeurbach
Copy link
Contributor Author

Is it possible these nodes are the top-levels such that they don't have one use but also aren't problematically multiply-instantiated?

Good question, I think in this case, we wouldn't hit the error, because such modules would be the "owning module" of themselves, and we'd immediately stop here:

circt/lib/Dialect/FIRRTL/Transforms/ResolvePaths.cpp

Line 52 in 75a192e

if (node->getModule() == owningModule)

I can add a small test case to be sure this works.

@mikeurbach
Copy link
Contributor Author

This is the exact test case I was going to write:

circt/test/Dialect/FIRRTL/resolve-paths.mlir

Lines 25 to 32 in 75a192e

// CHECK-LABEL: firrtl.circuit "TargetTopModule"
firrtl.circuit "TargetTopModule" {
// CHECK: firrtl.module @TargetTopModule() attributes {annotations = [{class = "circt.tracker", id = distinct[0]<>}]}
firrtl.module @TargetTopModule() {
// CHECK: %0 = firrtl.path reference distinct[0]<>
%0 = firrtl.unresolved_path "OMReferenceTarget:~TargetTopModule|TargetTopModule"
}
}

Does that cover your concern @dtzSiFive? Or were you thinking of another scenario?

@mikeurbach
Copy link
Contributor Author

I'm going to go ahead and merge this, but happy to add anything else in a follow up.

@mikeurbach mikeurbach merged commit 804cdbe into main Sep 5, 2024
@mikeurbach mikeurbach deleted the mikeurbach/ambiguous-path-error branch September 5, 2024 19:25
@dtzSiFive
Copy link
Contributor

Does that cover your concern @dtzSiFive? Or were you thinking of another scenario?

Nope, that covers it! Thanks! 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@dtzSiFive dtzSiFive dtzSiFive approved these changes

@prithayan prithayan Awaiting requested review from prithayan

@uenoku uenoku Awaiting requested review from uenoku

@darthscsi darthscsi Awaiting requested review from darthscsi darthscsi is a code owner

@seldridge seldridge Awaiting requested review from seldridge seldridge is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[FIRRTL] LowerClasses should enforce single instantiation

2 participants

@mikeurbach @dtzSiFive