Skip to content

[FIRRTL] parser: support rwprobe of open-agg instance results.#10018

Open
dtzSiFive wants to merge 2 commits intollvm:mainfrom
dtzSiFive:fix/rwprobe-into-open-agg
Open

[FIRRTL] parser: support rwprobe of open-agg instance results.#10018
dtzSiFive wants to merge 2 commits intollvm:mainfrom
dtzSiFive:fix/rwprobe-into-open-agg

Conversation

@dtzSiFive
Copy link
Contributor

Don't require the entire instance result is forceable.

Add test that fails before this change.

Builds on #10017 .

Refactor aggregate handling to common helper.
Don't require the entire instance result is forceable.

Add test that fails before this change.
@seldridge
Copy link
Member

For PRs that are stacked, you can use the "base" (or the --base argument if using gh) to actually stack them. E.g., the first PR has main as the base, but the second PR has the first PR's branch as the base. This then exposes the stacking directly and is supposed to update the second PR when the first PR goes in. (In practice this latter updating usually doesn't work unless you forcibly update main which is now disallowed, though. 🥲)

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. Nitty test comments.

Comment on lines 3923 to +3924
// Create bounce wire for the instance result.
// This may be an open aggregate, or other non-base type.
Copy link
Member

Choose a reason for hiding this comment

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

Mega-nit... I usually prefer line wrapping for paragraphs.

Comment on lines +1097 to +1098
wire inst_rcoa_a : RWProbe<UInt<1>>
wire inst_rcoa_passthru : RWProbe<UInt<1>>
Copy link
Member

Choose a reason for hiding this comment

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

Nit: what is the rc in rcoa? I assume the latter two characters are "open aggregate".

Copy link
Member

Choose a reason for hiding this comment

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

Nit: Consider moving the definitions of these wires closer to their usage sites.

Comment on lines +1095 to +1096
; CHECK-NEXT: %[[INST_RCOA_A:[^ ]+]] = firrtl.wire : !firrtl.rwprobe<uint<1>>
; CHECK-NEXT: %[[INST_RCOA_PASSTHRU:[^ ]+]] = firrtl.wire : !firrtl.rwprobe<uint<1>>
Copy link
Member

Choose a reason for hiding this comment

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

Nit: these wires should have predictable names? Is the regex capture necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mean it's all predictable until it's is broken by something?

If we want policy of assuming declaration names are stable enough that works for me.

The names make things fair bit easier to read that's for sure 👍.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, emphasize readability of the test. It's fine to assume that ImplicitSSAName will not break.

Looking at this with fresh eyes, it may be good to try to prune this test to its core essence. Is there anything here which is duplicated by previous tests that could be ignored so that this could be slimmed down? I'm also now questioning if we should, in a follow-on, add an opensubfield cache to avoid the duplicated subfields.

I gave the MLIR Testing Guide 1 a quick read to see if there was any guidance about SSA naming, but was more drawn to some of the other ideas which prompted the question above.

Comment on lines +1105 to +1107
; CHECK-NEXT: %[[RCOA_IN_A:.+]] = firrtl.opensubfield %[[RCOA_IN]][a]
; CHECK-NEXT: %[[RCOA_IN_BOUNCE_A2:.+]] = firrtl.opensubfield %[[RCOA_IN_BOUNCE]][a]
; CHECK-NEXT: firrtl.matchingconnect %[[RCOA_IN_A]], %[[RCOA_IN_BOUNCE_A2]]
Copy link
Member

Choose a reason for hiding this comment

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

Mega-nit: these checks are using a capture format that is different from the prior ones: .+ vs. [^ ]+.

; CHECK-NEXT: firrtl.ref.define %[[INST_RCOA_PASSTHRU]], %[[RCOA_IN_BOUNCE_RW]]
define inst_rcoa_a = rwprobe(rcoa.in.a)
define inst_rcoa_passthru = rcoa.in.rw
connect rcoa.in.a, UInt<1>(0)
Copy link
Member

Choose a reason for hiding this comment

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

Nit: connect is technically unnecessary for parsing. I can see having this so that this could theoretically be compiled to Verilog.

@dtzSiFive
Copy link
Contributor Author

For PRs that are stacked, you can use the "base" (or the --base argument if using gh) to actually stack them. E.g., the first PR has main as the base, but the second PR has the first PR's branch as the base. This then exposes the stacking directly and is supposed to update the second PR when the first PR goes in. (In practice this latter updating usually doesn't work unless you forcibly update main which is now disallowed, though. 🥲)

Thanks, yeah that's neat. Unfortunately I don't think that works if the branches aren't on the repo PR'ing to. Mostly because if I target the other PR branch it wouldn't be an llvm/circt PR anymore (don't think it'll let me)

And by the time was drafting this PR text and noticed it didn't seem worth rejiggering (or close/open) to get that to work.

Old habits re:using separate repo for my dev/PR branches... 😅

@seldridge
Copy link
Member

Unfortunately I don't think that works if the branches aren't on the repo PR'ing to. Mostly because if I target the other PR branch it wouldn't be an llvm/circt PR anymore (don't think it'll let me)

Ah, that's unfortunate. Yeah, I don't think that will work, then.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants