-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[mlir][vector] Add alignment attribute to vector operations. #152507
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
Changes from 11 commits
a97cbc6
158b91c
36949d1
a4d820f
e2ad0f9
92b3886
482ad75
9b451db
3180cd0
47db5b1
a714521
0f81b89
be906aa
46d9010
87958eb
c80adf0
dcf38e2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2054,7 +2054,9 @@ def Vector_GatherOp : | |
Variadic<Index>:$indices, | ||
VectorOfNonZeroRankOf<[AnyInteger, Index]>:$index_vec, | ||
VectorOfNonZeroRankOf<[I1]>:$mask, | ||
AnyVectorOfNonZeroRank:$pass_thru)>, | ||
AnyVectorOfNonZeroRank:$pass_thru, | ||
ConfinedAttr<OptionalAttr<I64Attr>, | ||
[AllAttrOf<[IntPositive, IntPowerOf2]>]>:$alignment)>, | ||
Results<(outs AnyVectorOfNonZeroRank:$result)> { | ||
|
||
let summary = [{ | ||
|
@@ -2085,6 +2087,12 @@ def Vector_GatherOp : | |
during progressively lowering to bring other memory operations closer to | ||
hardware ISA support for a gather. | ||
|
||
An optional `alignment` attribute allows to specify the byte alignment of the | ||
scatter operation. It must be a positive power of 2. The operation must access | ||
memory at an address aligned to this boundary. Violations may lead to | ||
architecture-specific faults or performance penalties. | ||
A value of 0 indicates no specific alignment requirement. | ||
|
||
Examples: | ||
|
||
```mlir | ||
|
@@ -2111,6 +2119,20 @@ def Vector_GatherOp : | |
"`into` type($result)"; | ||
let hasCanonicalizer = 1; | ||
let hasVerifier = 1; | ||
|
||
let builders = [ | ||
OpBuilder<(ins "VectorType":$resultType, | ||
"Value":$base, | ||
"ValueRange":$indices, | ||
"Value":$index_vec, | ||
"Value":$mask, | ||
"Value":$passthrough, | ||
CArg<"llvm::MaybeAlign", "llvm::MaybeAlign()">:$alignment), [{ | ||
return build($_builder, $_state, resultType, base, indices, index_vec, mask, passthrough, | ||
alignment.has_value() ? $_builder.getI64IntegerAttr(alignment->value()) : | ||
nullptr); | ||
}]> | ||
]; | ||
} | ||
|
||
def Vector_ScatterOp : | ||
|
@@ -2119,7 +2141,9 @@ def Vector_ScatterOp : | |
Variadic<Index>:$indices, | ||
VectorOfNonZeroRankOf<[AnyInteger, Index]>:$index_vec, | ||
VectorOfNonZeroRankOf<[I1]>:$mask, | ||
AnyVectorOfNonZeroRank:$valueToStore)> { | ||
AnyVectorOfNonZeroRank:$valueToStore, | ||
ConfinedAttr<OptionalAttr<I64Attr>, | ||
[AllAttrOf<[IntPositive, IntPowerOf2]>]>:$alignment)> { | ||
|
||
let summary = [{ | ||
scatters elements from a vector into memory as defined by an index vector | ||
|
@@ -2153,6 +2177,12 @@ def Vector_ScatterOp : | |
correspond to those of the `llvm.masked.scatter` | ||
[intrinsic](https://llvm.org/docs/LangRef.html#llvm-masked-scatter-intrinsics). | ||
|
||
An optional `alignment` attribute allows to specify the byte alignment of the | ||
scatter operation. It must be a positive power of 2. The operation must access | ||
memory at an address aligned to this boundary. Violations may lead to | ||
architecture-specific faults or performance penalties. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The violation is strangely defined here, why isn't this specified as UB? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In this particular case, there we some operations defined in this other PR #144344 which used this wording as documentation. I think changing the wording to be undefined behaviour is reasonable. Would something like the following be preferrable?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think
For the loads maybe we should instead use:
or something like that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think immediate UB is more suitable since using aligned loads on unaligned pointers is known to crash on some architectures There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point, but that means we can't speculate an aligned load anymore right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can open a PR to change the wording. Thanks @joker-eph ! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I checked LLVM and that seems like what we expect:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I personally prefer to avoid phrases like this unless we can provide a specific example. More generic terms like "UB" or "poison" tend to be more universal. |
||
A value of 0 indicates no specific alignment requirement. | ||
|
||
Examples: | ||
|
||
```mlir | ||
|
@@ -2177,14 +2207,29 @@ def Vector_ScatterOp : | |
"type($index_vec) `,` type($mask) `,` type($valueToStore)"; | ||
let hasCanonicalizer = 1; | ||
let hasVerifier = 1; | ||
|
||
let builders = [ | ||
OpBuilder<(ins "Value":$base, | ||
"ValueRange":$indices, | ||
"Value":$index_vec, | ||
"Value":$mask, | ||
"Value":$valueToStore, | ||
CArg<"llvm::MaybeAlign", "llvm::MaybeAlign()">: $alignment), [{ | ||
return build($_builder, $_state, base, indices, index_vec, mask, valueToStore, | ||
alignment.has_value() ? $_builder.getI64IntegerAttr(alignment->value()) : | ||
nullptr); | ||
}]> | ||
]; | ||
} | ||
|
||
def Vector_ExpandLoadOp : | ||
Vector_Op<"expandload">, | ||
Arguments<(ins Arg<AnyMemRef, "", [MemRead]>:$base, | ||
Variadic<Index>:$indices, | ||
FixedVectorOfNonZeroRankOf<[I1]>:$mask, | ||
AnyVectorOfNonZeroRank:$pass_thru)>, | ||
AnyVectorOfNonZeroRank:$pass_thru, | ||
ConfinedAttr<OptionalAttr<I64Attr>, | ||
[AllAttrOf<[IntPositive, IntPowerOf2]>]>:$alignment)>, | ||
Results<(outs AnyVectorOfNonZeroRank:$result)> { | ||
|
||
let summary = "reads elements from memory and spreads them into a vector as defined by a mask"; | ||
|
@@ -2216,6 +2261,12 @@ def Vector_ExpandLoadOp : | |
correspond to those of the `llvm.masked.expandload` | ||
[intrinsic](https://llvm.org/docs/LangRef.html#llvm-masked-expandload-intrinsics). | ||
|
||
An optional `alignment` attribute allows to specify the byte alignment of the | ||
load operation. It must be a positive power of 2. The operation must access | ||
memory at an address aligned to this boundary. Violations may lead to | ||
architecture-specific faults or performance penalties. | ||
A value of 0 indicates no specific alignment requirement. | ||
|
||
Note, at the moment this Op is only available for fixed-width vectors. | ||
|
||
Examples: | ||
|
@@ -2246,14 +2297,29 @@ def Vector_ExpandLoadOp : | |
"type($base) `,` type($mask) `,` type($pass_thru) `into` type($result)"; | ||
let hasCanonicalizer = 1; | ||
let hasVerifier = 1; | ||
|
||
let builders = [ | ||
OpBuilder<(ins "VectorType":$resultType, | ||
"Value":$base, | ||
"ValueRange":$indices, | ||
"Value":$mask, | ||
"Value":$passthrough, | ||
CArg<"llvm::MaybeAlign", "llvm::MaybeAlign()">:$alignment), [{ | ||
return build($_builder, $_state, resultType, base, indices, mask, passthrough, | ||
alignment.has_value() ? $_builder.getI64IntegerAttr(alignment->value()) : | ||
nullptr); | ||
}]> | ||
]; | ||
} | ||
|
||
def Vector_CompressStoreOp : | ||
Vector_Op<"compressstore">, | ||
Arguments<(ins Arg<AnyMemRef, "", [MemWrite]>:$base, | ||
Variadic<Index>:$indices, | ||
FixedVectorOfNonZeroRankOf<[I1]>:$mask, | ||
AnyVectorOfNonZeroRank:$valueToStore)> { | ||
AnyVectorOfNonZeroRank:$valueToStore, | ||
ConfinedAttr<OptionalAttr<I64Attr>, | ||
[AllAttrOf<[IntPositive, IntPowerOf2]>]>:$alignment)> { | ||
|
||
let summary = "writes elements selectively from a vector as defined by a mask"; | ||
|
||
|
@@ -2284,6 +2350,12 @@ def Vector_CompressStoreOp : | |
correspond to those of the `llvm.masked.compressstore` | ||
[intrinsic](https://llvm.org/docs/LangRef.html#llvm-masked-compressstore-intrinsics). | ||
|
||
An optional `alignment` attribute allows to specify the byte alignment of the | ||
store operation. It must be a positive power of 2. The operation must access | ||
memory at an address aligned to this boundary. Violations may lead to | ||
architecture-specific faults or performance penalties. | ||
A value of 0 indicates no specific alignment requirement. | ||
|
||
Note, at the moment this Op is only available for fixed-width vectors. | ||
|
||
Examples: | ||
|
@@ -2312,6 +2384,17 @@ def Vector_CompressStoreOp : | |
"type($base) `,` type($mask) `,` type($valueToStore)"; | ||
let hasCanonicalizer = 1; | ||
let hasVerifier = 1; | ||
let builders = [ | ||
OpBuilder<(ins "Value":$base, | ||
"ValueRange":$indices, | ||
"Value":$mask, | ||
"Value":$valueToStore, | ||
CArg<"llvm::MaybeAlign", "llvm::MaybeAlign()">:$alignment), [{ | ||
return build($_builder, $_state, base, indices, valueToStore, mask, | ||
alignment.has_value() ? $_builder.getI64IntegerAttr(alignment->value()) : | ||
nullptr); | ||
}]> | ||
]; | ||
} | ||
|
||
def Vector_ShapeCastOp : | ||
|
Uh oh!
There was an error while loading. Please reload this page.