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

Remove tt::target::DataType::None #1103

Merged
merged 1 commit into from
Oct 30, 2024
Merged

Remove tt::target::DataType::None #1103

merged 1 commit into from
Oct 30, 2024

Conversation

jnie-TT
Copy link
Contributor

@jnie-TT jnie-TT commented Oct 29, 2024

Closes #1102

Copy link
Contributor

@svuckovicTT svuckovicTT left a comment

Choose a reason for hiding this comment

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

Thanks Jackson! :)

@@ -18,9 +18,9 @@ table ToMemoryConfigOp {
table ToLayoutOp {
in: tt.target.TensorRef;
layout: tt.target.TensorLayout;
dtype: tt.target.DataType;
dtype: tt.target.DataType = null;
Copy link
Contributor

Choose a reason for hiding this comment

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

There's no need to set this to null, each field is optional in flatbuffers, and defaults to 0/null.

Copy link
Contributor Author

@jnie-TT jnie-TT Oct 29, 2024

Choose a reason for hiding this comment

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

For enums it has to be set, 0/null only works for flatbuffers::Offset types which tables get compiled to. Enums get directly compiled to C++ enums. That's why I previously had to add a NONE type to the enum type to make it behave similarly. If we set it to 0 it would assume we're assigning the enum value that maps to 0.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see, thanks for letting me know!

include/ttmlir/Target/TTNN/program.fbs Outdated Show resolved Hide resolved
@jnie-TT jnie-TT force-pushed the jnie/none_data_type branch 3 times, most recently from bb70931 to fb5d6c1 Compare October 29, 2024 19:06
@@ -35,8 +35,8 @@ void run(const ::tt::target::ttnn::ToLayoutOp *op, ProgramContext &context) {
std::optional<::ttnn::MemoryConfig> memoryConfig = std::nullopt;
::ttnn::Device *device = nullptr;

if (op->dtype() != ::tt::target::DataType::None) {
dtype = ::tt::runtime::ttnn::utils::toTTNNDataType(op->dtype());
if (op->dtype()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Will this work for Float32?

Copy link
Contributor Author

@jnie-TT jnie-TT Oct 29, 2024

Choose a reason for hiding this comment

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

Yes it will because the enum is wrapped in a flatbuffers::Optional (because we're assigning null in the fbs file), so this check will solely check if the Optional has a value and is not a flatbuffers::nullopt. That's also why I dereference the dtype on the next line to extract the enum value.

@jnie-TT jnie-TT force-pushed the jnie/none_data_type branch 3 times, most recently from d9d0cd9 to 146fc32 Compare October 30, 2024 14:47
@jnie-TT jnie-TT force-pushed the jnie/none_data_type branch from 146fc32 to 3840b83 Compare October 30, 2024 14:48
@jnie-TT jnie-TT merged commit 22a06f2 into main Oct 30, 2024
13 checks passed
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.

Remove tt::target::DataType::None
5 participants