Skip to content

Conversation

@lhutton1
Copy link
Contributor

This commit adds support for representing scalable vectors using the string data type format. For example, "float32xvscalex4" may be used to represent the following scalable type: DataType(kDLFloat, 32, /*lanes=*/4, /*is_scalable=*/true).

Co-authored-by: Elen Kalda [email protected]
Co-authored-by: Neil Hickey [email protected]

This commit adds support for representing scalable vectors using the
string data type format. For example, "float32xvscalex4" may be used
to represent the following scalable type:
`DataType(kDLFloat, 32, /*lanes=*/4, /*is_scalable=*/true)`.

Co-authored-by: Elen Kalda <[email protected]>
Co-authored-by: Neil Hickey <[email protected]>
Change-Id: I883dbdf29f500cc6bf6f9dc3097fa1d5af12b020
Change-Id: Iea28d0c276eed75e9dc2d2f17ea153ad7100adad
@lhutton1
Copy link
Contributor Author

@tvm-bot rerun

Copy link
Contributor

@ekalda ekalda left a comment

Choose a reason for hiding this comment

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

Thanks @lhutton1 LGTM in a general, just one comment :)

}
/*! \return whether type is a scalar type. */
bool is_scalar() const { return lanes() == 1; }
bool is_scalar() const { return !is_scalable_vector() && lanes() == 1; }
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would make more sense to use !is_scalable_or_fixed_length_vector() here. The current version is going to throw an error if applied on a scalable vector.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Due to placing a call to is_scalable_vector() before lanes(), is_scalar() should work with scalable vectors in its current form, I'll add some tests for this. I don't think we can simply return !is_scalable_or_fixed_length_vector() as it wouldn't account for the case when lanes == 0.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok yes, thinking about it, this probably is the most solid way to do it, even though it reads a bit awkward 👍

Change-Id: I3e6c56a0f1e171278c50fefe10bddd1feeca1b69
Copy link
Contributor

@ekalda ekalda left a comment

Choose a reason for hiding this comment

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

LGTM!

@ekalda ekalda merged commit 563ef95 into apache:main Feb 27, 2024
@ekalda
Copy link
Contributor

ekalda commented Feb 27, 2024

Thanks @lhutton1!

@tqchen
Copy link
Member

tqchen commented Feb 27, 2024

there is a regression due to concurrent merge, cc @Lunderberg

@lhutton1
Copy link
Contributor Author

thanks for raising @tqchen, I'm taking a look now

lhutton1 added a commit to lhutton1/tvm that referenced this pull request Feb 27, 2024
A default value for lanes was unintentionally removed in apache#16612, this
PR fixes this which in turn fixes the test failure seen in
`test_tensor_dtype_lanes` in CI.

Change-Id: If1b06cb836d62e85620971fd1ad0498c9fdc66b9
@lhutton1
Copy link
Contributor Author

Apologies for missing this previously, I've uploaded #16649 which I'd expect to fix the failing test case

@ekalda
Copy link
Contributor

ekalda commented Feb 27, 2024

Any idea why the CI didn't catch this?

@lhutton1
Copy link
Contributor Author

CI was last run on the patch yesterday (26th Feb) while the PR that caught the issue was merged a week ago #16563. I didn't rebase before pushing, but had expected CI to do this automatically.

I think it might have something to do with a missing call to merge_with_main()(link) in the unity_jenkinsfile.groovy file since the other jenkinsfiles used in CI make calls to this, which presumably updates the PR branch before CI is run

ekalda pushed a commit that referenced this pull request Feb 28, 2024
A default value for lanes was unintentionally removed in #16612, this
PR fixes this which in turn fixes the test failure seen in
`test_tensor_dtype_lanes` in CI.
@lhutton1 lhutton1 deleted the p3-scalable-dtype-strings branch February 28, 2024 13:40
Lunderberg pushed a commit to Lunderberg/tvm that referenced this pull request Mar 12, 2024
This commit adds support for representing scalable vectors using the
string data type format. For example, "float32xvscalex4" may be used
to represent the following scalable type:
`DataType(kDLFloat, 32, /*lanes=*/4, /*is_scalable=*/true)`.


---------


Co-authored-by: Elen Kalda <[email protected]>
Co-authored-by: Neil Hickey <[email protected]>
Lunderberg pushed a commit to Lunderberg/tvm that referenced this pull request Mar 12, 2024
A default value for lanes was unintentionally removed in apache#16612, this
PR fixes this which in turn fixes the test failure seen in
`test_tensor_dtype_lanes` in CI.
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.

3 participants