-
Notifications
You must be signed in to change notification settings - Fork 787
Allow native vector intrinsics with fixed component types #7597
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
base: main
Are you sure you want to change the base?
Conversation
Several intrinsics that support native vectors return the same element type regardless of overload. For native vectors, these need to return a vector of size matching the overload with the fixed element type. This provides the source generation to allow it and the changes to the related lowering operations to generate the correct DXIL. This includes some queries that return boolean information about the vector components in a boolean vector output and also the unary bit operations which operate on integers and return integers containing information about the component bits. Fixes microsoft#7342
5843483
to
99e1364
Compare
✅ With the latest revision this PR passed the C/C++ code formatter. |
Enables native vectors for isspecial operations. Left out of previous commit. Test verifies current behavior, but will need to change when microsoft#7588 is closed.
// CHECK: call <13 x i32> @dx.op.unaryBits.v13i64(i32 32, <13 x i64> [[lvec2]]) ; FirstbitLo(value) | ||
uRes += firstbitlow(lVec2); | ||
|
||
// CHECK: call <13 x i32> @dx.op.unaryBits.v13i32(i32 33, <13 x i32> [[uvec1]]) ; FirstbitHi(value) |
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.
This isn't testing the full expansion.
@@ -1406,6 +1406,7 @@ def populate_dxil_operations(self): | |||
# $o in a parameter type means the overload type | |||
# $r in a parameter type means the resource type | |||
# $cb in a parameter type means cbuffer legacy load return type | |||
# $otpl{component} in a return type means the overload template shape with the specified component type |
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.
I have a hard time reading overloads with this name. What about just $o_{component}
for overload, but with fixed component type? I think it would be easier to read.
If necessary, this pattern could be extended to the $x0
and $x1
pattern, with $x0_{component}
.
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.
I just have a minor issue with the otpl
prefix.
Several intrinsics that support native vectors return the same element type regardless of overload. For native vectors, these need to return a vector of size matching the overload with the fixed element type. This provides the source generation to allow it and the changes to the related lowering operations to generate the correct DXIL.
This includes some queries that return boolean information about the vector components in a boolean vector output and also the unary bit operations which operate on integers and return integers containing information about the component bits.
Incidentally moves some intrinsics that have long since not been scalarized out of the scalarized test. They were updated to expect the new output, but were in the wrong location and not tested as thoroughly as their native vector counterparts.
Fixes #7342