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

Avoid emitting 'const const' for const vecs of const elements #3393

Merged
merged 2 commits into from Jun 28, 2023
Merged

Avoid emitting 'const const' for const vecs of const elements #3393

merged 2 commits into from Jun 28, 2023

Conversation

trilorez
Copy link
Contributor

@trilorez trilorez commented Jun 28, 2023

Contributor Checklist

  • Did you add Scaladoc to every public function/method?
  • Did you add at least one test demonstrating the PR?
  • Did you delete any extraneous printlns/debugging code?
  • Did you specify the type of improvement?
  • Did you add appropriate documentation in docs/src?
  • Did you request a desired merge strategy?
  • Did you add text to be included in the Release Notes for this change?

Type of Improvement

  • Bugfix

Desired Merge Strategy

  • Squash: The PR will be squashed and merged (choose this if you have no preference).

Release Notes

Multiple consecutive 'const' modifiers are no longer emitted when emitting a const vector of const elements.

Reviewer Checklist (only modified by reviewer)

  • Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
  • Did you mark the proper milestone (Bug fix: 3.5.x or 3.6.x depending on impact, API modification or big change: 5.0.0)?
  • Did you review?
  • Did you check whether all relevant Contributor checkboxes have been checked?
  • Did you do one of the following when ready to merge:
    • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
    • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

@trilorez
Copy link
Contributor Author

trilorez commented Jun 28, 2023

I realize now I need to handle vecs of vecs where the intermediate vec isn’t const
Edit: this is handled now

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

The PR needs a label for the release generation flow. Could you do two things:

  1. Add the label. Probably "Codegen"
  2. Populate the "Release Notes" section of the PR template.

Jack wrote some cool automation to use these two things to automatically generate the release notes.

@trilorez
Copy link
Contributor Author

The PR needs a label for the release generation flow. Could you do two things:

1. Add the label. Probably "Codegen"

2. Populate the "Release Notes" section of the PR template.

I added the release notes. I don't believe I'm able to add a label (I'm not a member of this repo) unless I'm missing something.

@mwachs5 mwachs5 added the Backend Code Generation Affects backend code generation, will be included in release notes label Jun 28, 2023
@mwachs5 mwachs5 added this to the 6.0 milestone Jun 28, 2023
@mwachs5 mwachs5 added the Please Merge Accepted PRs that are ready to be merged. Useful when waiting on CI. label Jun 28, 2023
@mergify mergify bot merged commit a6728aa into chipsalliance:main Jun 28, 2023
16 of 17 checks passed
@trilorez trilorez deleted the const-vec-emit branch June 28, 2023 21:28
Comment on lines +346 to +352
case ConstType(underlying: Type) => {
// Avoid emitting multiple consecurive 'const', which can otherwise occur for const vectors of const elements
if (!lastEmittedConst) {
b ++= "const "
}
s(underlying, true)(b, indent)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm of two minds about this solution. I'm a bit concerned because this same issue is solved for directions in the Converter (

private def firrtlUserDirOf(d: Data): SpecifiedDirection = d match {
), and presumably we don't have it solved for probes. I'm worried that when we fold the Converter and Serializer together, we will lose this fix. I grant there is some elegance to the spot in that it ensures that any FIRRTL IR will be emitted properly whereas the Converter fix doesn't guarantee that. But we don't create FIRRTL IR any other way so I think I prefer the further upstream fix.

Better yet would be if we could pull the fix further up into the actual construction of the Chisel types such that these fixups aren't necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend Code Generation Affects backend code generation, will be included in release notes Please Merge Accepted PRs that are ready to be merged. Useful when waiting on CI.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants