-
Notifications
You must be signed in to change notification settings - Fork 304
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] enable properties for inherent attributes #7750
Conversation
f38c9b2
to
5dbb930
Compare
On a |
This is a big change to clean up our implementation of `inferReturnTypes` in an effort to get ourselves ready to enable properties in the FIRRTL dialect. We had structured our API so that `inferReturnType` would call out to a simpler version of itself with some of the useless arguments removed. This prevented us from using op adaptors to abstract over whether or not an inherent attribute was contained inside the attr-dict or the properties. This change keeps the old structure of a two level API, but with different boundaries: The large API takes all arguments, creates an adapter, pulls out the necessary attributes and then calls in to the simpler interface. FIRParser uses the simpler API when inferring return types. The simpler interface is now specific to each operation and not common with other operations. This last change caused a problem for `parsePrimExp`, which relied on a generic interface to create all expressions. This function is now templated over exactly how many arguments the specific prim op takes, parses exactly that many, and splats them out when calling `inferReturnType`. As an upside to this, we can also call a more specific builder for each operation, which should speed up building operations when we move to properties.
This enables properties in the FIRRTL dialect. Some op parsers which called `inferReturnTypes` had to be updated to store inherent attributes as properties on the OperationState, as the call to `inferReturnTypes` expects properties to have already been populated. This is a change that we should make for all operation parsers and builders, to make things faster, but is not strictly necessary at this time.
5dbb930
to
ddc2f65
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really cool to see this migrated over to properties. LGTM!
Thanks for taking a look! |
Impressive about |
[FIRRTL] Clean up inferReturnTypes implementation
739cf51
This is a big change to clean up our implementation of
inferReturnTypes
in an effort to get ourselves ready to enableproperties in the FIRRTL dialect. We had structured our API so that
inferReturnType
would call out to a simpler version of itself withsome of the useless arguments removed. This prevented us from using op
adaptors to abstract over whether or not an inherent attribute was
contained inside the attr-dict or the properties.
This change keeps the old structure of a two level API, but with
different boundaries: The large API takes all arguments, creates an
adapter, pulls out the necessary attributes and then calls in to the
simpler interface. FIRParser uses the simpler API when inferring return
types. The simpler interface is now specific to each operation and not
common with other operations.
This last change caused a problem for
parsePrimExp
, which relied on ageneric interface to create all expressions. This function is now
templated over exactly how many arguments the specific prim op takes,
parses exactly that many, and splats them out when calling
inferReturnType
. As an upside to this, we can also call a morespecific builder for each operation, which should speed up building
operations when we move to properties.
[FIRRTL] enable properties for inherent attributes
f38c9b2
This enables properties in the FIRRTL dialect. Some op parsers which
called
inferReturnTypes
had to be updated to store inherent attributesas properties on the OperationState, as the call to
inferReturnTypes
expects properties to have already been populated. This is a change
that we should make for all operation parsers and builders, to make
things faster, but is not strictly necessary at this time.