Skip to content
This repository has been archived by the owner on Aug 20, 2024. It is now read-only.

Use "_" for Inline Name Mangling, Respect Namespaces #901

Merged
merged 3 commits into from
Oct 5, 2018

Conversation

seldridge
Copy link
Member

@seldridge seldridge commented Sep 27, 2018

Summary of changes

  • Inline pass now uses _ as a delimiter. Previously, $ was used.
  • When determining an Inline prefix, the prefix must be unique with respect to the enclosing module's Namespace

Overview

This does not change the underlying algorithm of Inline. The only major change is that a returned flattened instance is converted to a bundle with Uniquify.enumerateNames. The prefix is then generated for that bundle with respect to the enclosing Module's namespace (using Uniquify.findValidPrefix). Additionally, module changes are tracked via a RenameMap as opposed to assuming that one prefix will work.

Note: this does not inline with "prefix unique" names. This is somewhat expensive to do as it requires expanding all names in the namespace out to include their prefixes. There's a discussion of the limitations associated with this via a method that PR #900 introduces in this thread.

Small changes

  • The two used Uniquify methods are made private [firrtl]
  • findValidPrefix wants a HashSet as input. I expose this with a new method, cloneUnderlying, added to Namespace

Miscellaneous

Copy link
Contributor

@chick chick left a comment

Choose a reason for hiding this comment

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

This looks like a clean implementation to me. Tests look like the back up the changes.
I don't feel particularly qualified to opine on the consequence of these changes to the
firrtl/chisel ecosystem. I defer to @seldridge @jackkoenig for that determination

@seldridge
Copy link
Member Author

In terms of implications:

  • Anybody using inlining/flattening will now see _ in their output Verilog as opposed to $. People relying on explicit signal names will have to update.
  • Anybody who wrote a transform that relies on counting $ in a flattened design will break.

I expect that all of these are exceedingly rare cases.

@chick: Since this breaks Chisel temporarily, what's the correct strategy to merge this? I'm assuming that I merge this and then merge the companion PR once Jenkins pulls in upstream FIRRTL. Jenkins does pull in upstream FIRRTL, yes? While I'm doing this, all FIRRTL PRs will break as they'll be trying to use upstream Chisel. After everything is updated, this will then requires developers to use publishLocal verions of Chisel and FIRRTL upstream going forward until 3.2. I assume this is normal and okay?

@jackkoenig: Are you okay with this without prefix uniqueness? I was thinking that would be a follow-up PR once I look at the performance implications, if any, on a large design like Rocket Chip.

Pending these questions, I'll intend to get this in and then quickly merge chipsalliance/chisel#898 (which is already approved). I have a follow-up ready to go for FIRRTL that will fix Verilog keyword name mangling.

@ucbjrl
Copy link
Contributor

ucbjrl commented Oct 3, 2018

I believe if you include the string [skip chisel tests] in the commit message, travis will bypass the chisel tests.

Jenkins does build the FIRRTL master branch as part of its chisel testing, so this may temporarily cause chisel tests to fail (depending on how quickly you can commit the chisel companion PR). This does happen from time to time, so it's not unexpected.

We can specify specific branches/PRs/SHA1s for all of the BIG6 repositories when triggering a manual Jenkins build. I would like to do this (before starting the chain of commits to masters) to verify that we do have a consistent global state.

This adds a method, cloneUnderlying, to Namespace that returns a copy of
the underlying mutable.HashSet. This is useful for constructing a
Namespace that you would like to manipulate manually without using
Namespace's methods to generate temporaries.

Signed-off-by: Schuyler Eldridge <[email protected]>
This makes findValidPrefix and enumerateNames both private to
FIRRTL (previously, these were private). This enables their use for name
generation by other FIRRTL passes/transforms.

Signed-off-by: Schuyler Eldridge <[email protected]>
Summary of changes:
  - Use "_" as an inlining delimiter instead of "$"
  - Makes inlining avoid namespace conflicts

This changes the delimiter used for inlining to "_" instead of "$". This
avoids problems with buggy parsers that may not handle "$" correctly. As
ClockListTransform relies on the explicit use of "$", the delimiter is a
FIRRTL-private val that the ClockListTransform overrides (to the original
"$").

Namespace conflicts could occur previously, but are very rare as users
will almost never use "$" in a name (even though it's allowed by both the
FIRRTL and Verilog specifications). Moving to "_" increases the
probability of namespace conflicts occurring. This adds explicit checking
that inlined names will not introduce namespace conflicts and that
generated names are prefix unique (as defined in the spec).

Note: inlined modules may not have unique prefixes. A test is included
that this is the case and an ignored test shows what prefix uniqueness
would look like.

MISC:
  - [skip chisel tests]: Changing the delimiter causes the Chisel
    InlineSpec to fail as this explicitly checks for "$".

Signed-off-by: Schuyler Eldridge <[email protected]>
@seldridge
Copy link
Member Author

@ucbjrl: Great. Thanks for the pointer to [skip chisel tests]. I'm currently using that to get this PR to pass.

The specific PRs that should be tested together with the BIG6 (freechips is starting to sound more and more like a college football conference...) are:

These are both rebased onto master, approved, and ready to go. I've tested them locally for compatibility, but have not done a local BIG6 test.

A BIG6 test on Jenkins before serial master commits makes sense to me. Good suggestion.

Is the manual Jenkins build with branch pointers something that I can initiate (with similar tags that Jenkins will understand), or is that something that you will have to do?

@ucbjrl
Copy link
Contributor

ucbjrl commented Oct 3, 2018

You need to have Jenkins credentials (be able to log in) to run a manual Jenkins build. We don't have an anonymous public interface for this.

@ucbjrl
Copy link
Contributor

ucbjrl commented Oct 4, 2018

@seldridge
Copy link
Member Author

Thanks a lot @ucbjrl. I'll take care of the serial merge later today.

@seldridge seldridge merged commit ed70957 into chipsalliance:master Oct 5, 2018
@seldridge seldridge deleted the issue-729.1 branch October 12, 2018 17:02
@ucbjrl ucbjrl added this to the 1.2.0 milestone Dec 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants