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] Support Prefixing of Grand Central Interfaces #2020

Merged
merged 6 commits into from
Oct 21, 2021

Conversation

seldridge
Copy link
Member

@seldridge seldridge commented Oct 20, 2021

Add support for prefixing Grand Central Interfaces with both a module-level, outer prefix (as set by the PrefixModules pass) and with an inner PrefixInterfacesAnnotation.

This is implemented by adding an optional field to the bundle type called "prefix" that is set by PrefixModules based on where the interface is instantiated. This prefix is also applied to the name of the parent and companion modules.

During the Grand Central interfaces pass, this prefix is combined with an optional prefix read from a PrefixInterfacesAnnotation to prefix each interface.

@seldridge seldridge force-pushed the dev/seldridge/gct-interface-prefix-modules branch from 37188a3 to f3d79e6 Compare October 21, 2021 03:54
@seldridge seldridge marked this pull request as ready for review October 21, 2021 03:56
Update Grand Central Interfaces with a prefix if one is set during the
PrefixModules pass.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Add one test to the PrefixModules test that annotations associated with
a Grand Central interface are updated if they are in a module prefix
scope.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Add a getter to retrieve the "prefix" field of an AugmentedBundleType.
This is a utility to provides easy access to a new field that
PrefixModules is adding to the outermost AugmentedBundleType.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Change the Grand Central Views/Interfaces pass to apply an outer
module-level prefix (derived from a NestedPrefixModulesAnnotation that
was handled by the PrefixModules pass) and an inner prefix set by an
optional PrefixInterfacesAnnotation.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Add a test that the Grand Central Views/Interfaces pass properly
consumes a PrefixInterfacesAnnotation, removes it, and uses its
information to apply a prefix to all interfaces in a circuit.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Update FIRRTL rationale document with information about how Grand
Central-generated interfaces can be prefixed.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
@seldridge seldridge force-pushed the dev/seldridge/gct-interface-prefix-modules branch from f3d79e6 to 366b687 Compare October 21, 2021 04:57
Copy link
Contributor

@fabianschuiki fabianschuiki left a comment

Choose a reason for hiding this comment

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

As far as my understanding of the Scala implementation goes, this looks really nice!

Comment on lines +196 to +226
AnnotationSet annotations(module);
if (!annotations.hasAnnotation(
"sifive.enterprise.grandcentral.ViewAnnotation"))
return;
auto prefixFull = (outerPrefix + innerPrefix).str();
SmallVector<Attribute> newAnnotations;
for (auto anno : annotations) {
if (!anno.isClass("sifive.enterprise.grandcentral.ViewAnnotation")) {
newAnnotations.push_back(anno.getDict());
continue;
}

NamedAttrList newAnno;
for (auto pair : anno.getDict()) {
if (pair.first == "name") {
newAnno.append(
pair.first,
builder.getStringAttr(Twine(prefixFull) +
pair.second.cast<StringAttr>().getValue()));
continue;
}
newAnno.append(pair.first, pair.second);
}
newAnnotations.push_back(
DictionaryAttr::getWithSorted(builder.getContext(), newAnno));

// Record that we need to apply this prefix to the interface definition.
if (anno.getMember<StringAttr>("type").getValue() == "parent")
interfacePrefixMap[anno.getMember<IntegerAttr>("id")] = prefixFull;
}
AnnotationSet(newAnnotations, builder.getContext()).applyToOperation(module);
Copy link
Contributor

Choose a reason for hiding this comment

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

It's sad that there is no better way to do dictionary attr mutation in MLIR yet. I totally see why you'd want something like AnnotationSet::map or filter_map here. Maybe we should start to curate a list of "nice-to-have refactorings" that people can pick up if they're bored or want to jump in. Maybe as some "help wanted" issue?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this rewrite just to mutate one value feels bad. I've seen this come up twice so far: (1) annotation scattering does this type of transformation and (2) this pass. I can open up some help wanted issues.

@seldridge seldridge merged commit 8e3be75 into main Oct 21, 2021
@seldridge seldridge deleted the dev/seldridge/gct-interface-prefix-modules branch October 21, 2021 15:55
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