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

Bytecode implementation for StableHLO #60

Merged
merged 18 commits into from
Sep 2, 2022
Merged

Conversation

GleasonK
Copy link
Member

@GleasonK GleasonK commented Aug 29, 2022

This PR plays a role in #34. There is still a little more work to do before closing this issue, as documented in bytecode.md of this PR.

  • Implemented bytecode for StableHLO, all attributes and types. The changes here are largely based off BuiltinDialectBytecode.cpp.
  • Added a test bytecode.mlir:
    • Ensures that stablehlo-opt and stablehlo-opt -emit-bytecode file.mlir | stablehlo-opt produce the same results.
    • Uses stablehlo-bytecode debug trace to ensure that all attrs/types have bytecoding implemented.
  • Added documentation of work, findings, and open questions in bytecode.md.

@GleasonK
Copy link
Member Author

Adding Mehdi as a reviewer. I think my biggest area of concern is the datatypes chosen to represent data. Just about everything is represented as a varint, svarint, or array of svarint[]. I'm not sure if this is ideal for all the given datatypes, or if APInt should be used anywhere.

Additionally, note the test cases run in bytecode.mlir, they are bash-specific. Perhaps there is a better way to verify round-trip? I think I saw some conversation regarding this on the LLVM bytecode implementation review, not sure if anything ever came of that.

@joker-eph
Copy link
Contributor

Adding Mehdi as a reviewer. I think my biggest area of concern is the datatypes chosen to represent data. Just about everything is represented as a varint, svarint, or array of svarint[]. I'm not sure if this is ideal for all the given datatypes, or if APInt should be used anywhere.

The (s)varint are the right choice right now for anything stored as integers (up to 64 bits).
If we have any attribute storing an APInt in memory, we shouldn't use this. But that seems unusual: do we have such cases?

docs/bytecode.md Outdated Show resolved Hide resolved
docs/bytecode.md Outdated Show resolved Hide resolved
docs/bytecode.md Outdated Show resolved Hide resolved
docs/bytecode.md Show resolved Hide resolved
docs/bytecode.md Show resolved Hide resolved
docs/bytecode.md Outdated Show resolved Hide resolved
docs/bytecode.md Outdated Show resolved Hide resolved
stablehlo/dialect/StablehloBytecode.cpp Show resolved Hide resolved
stablehlo/dialect/StablehloBytecode.cpp Show resolved Hide resolved
stablehlo/dialect/StablehloBytecode.cpp Show resolved Hide resolved
stablehlo/dialect/StablehloBytecode.cpp Outdated Show resolved Hide resolved
stablehlo/tests/bytecode.mlir Outdated Show resolved Hide resolved
outputBatchDimension: svarint
outputFeatureDimension: svarint
outputSpatialDimensions: svarint[]
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm I don't think that you pushed this update?

@@ -0,0 +1,695 @@
/* Copyright 2022 The StableHLO Authors.
StablehloBytecode.cpp - StableHLO Bytecode Implementation */
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's use the usual license blurb here?


/// This enum contains marker codes used to indicate which attribute is
/// currently being decoded, and how it should be decoded. The order of these
/// codes should generally be unchanged, as any changes will inevitably break
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you anticipate situations where the order should be changed? (I guess, this is an eventuality that "generally" is preparing the reader for).

stablehlo/dialect/StablehloBytecode.cpp Show resolved Hide resolved
stablehlo/dialect/StablehloBytecode.cpp Show resolved Hide resolved
docs/bytecode.md Outdated
the `strings` command can be used to see what attributes were missed:

_Note: The following trace is from a previous revision where the `scatter` attribute
was not implemented. Currently all types/attrs are implemented and log only shows
Copy link
Contributor

Choose a reason for hiding this comment

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

How about we remove this sentence and its accompanying output in the printout below? "The following trace is from a previous revision where the scatter attribute was not implemented". Even without stablehlo.scatter, the output is educational enough?

stablehlo/tests/bytecode.mlir Outdated Show resolved Hide resolved
@GleasonK GleasonK merged commit 4f7fe55 into openxla:main Sep 2, 2022
@GleasonK GleasonK deleted the bytecode branch September 2, 2022 14:38
@burmako burmako added the Migrate to MHLO PR that needs to be migrated to MLIR-HLO label Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Integrations Migrate to MHLO PR that needs to be migrated to MLIR-HLO
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants