-
Notifications
You must be signed in to change notification settings - Fork 16.7k
[Intrinsics][AArch64] Add intrinsics for masking off aliasing vector lanes #117007
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 all commits
f9e5a7c
071728f
80a72ca
daa2ac4
3fcb9e8
6628a98
0644542
75af361
5f563d9
24df6bf
ec37dfa
8d81955
8a09412
45cbaff
1b7b0da
0a0de88
54d32ad
2066929
9b3a71a
215d2e7
ec2bfed
9f5f91a
eb8d5af
c3d6fc8
9c5631d
52fca12
9a985ab
b09d354
56f9a6b
26bf362
a84e5e2
054f859
970e7f9
fddda14
36be558
c3d2acf
8af5019
558bc3e
32e0192
3d7c2da
5402e27
5075b5f
d85d375
4dedf42
33be150
587a25c
3abc7ba
8eb12a0
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 | ||||
|---|---|---|---|---|---|---|
|
|
@@ -24105,6 +24105,130 @@ Examples: | |||||
| %wide.masked.load = call <4 x i32> @llvm.masked.load.v4i32.p0v4i32(<4 x i32>* %3, i32 4, <4 x i1> %active.lane.mask, <4 x i32> poison) | ||||||
|
|
||||||
|
|
||||||
| .. _int_loop_dependence_war_mask: | ||||||
|
|
||||||
| '``llvm.loop.dependence.war.mask.*``' Intrinsics | ||||||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||||||
|
|
||||||
| Syntax: | ||||||
| """"""" | ||||||
| This is an overloaded intrinsic. | ||||||
|
|
||||||
| :: | ||||||
|
|
||||||
| declare <4 x i1> @llvm.loop.dependence.war.mask.v4i1(ptr %ptrA, ptr %ptrB, i64 immarg %elementSize) | ||||||
| declare <8 x i1> @llvm.loop.dependence.war.mask.v8i1(ptr %ptrA, ptr %ptrB, i64 immarg %elementSize) | ||||||
| declare <16 x i1> @llvm.loop.dependence.war.mask.v16i1(ptr %ptrA, ptr %ptrB, i64 immarg %elementSize) | ||||||
| declare <vscale x 16 x i1> @llvm.loop.dependence.war.mask.nxv16i1(ptr %ptrA, ptr %ptrB, i64 immarg %elementSize) | ||||||
|
|
||||||
|
|
||||||
| Overview: | ||||||
| """"""""" | ||||||
|
|
||||||
| Given a vector load from %ptrA followed by a vector store to %ptrB, this | ||||||
| instruction generates a mask where an active lane indicates that the | ||||||
| write-after-read sequence can be performed safely for that lane, without the | ||||||
| danger of a write-after-read hazard occurring. | ||||||
|
|
||||||
| A write-after-read hazard occurs when a write-after-read sequence for a given | ||||||
| lane in a vector ends up being executed as a read-after-write sequence due to | ||||||
| the aliasing of pointers. | ||||||
|
|
||||||
| Arguments: | ||||||
| """""""""" | ||||||
|
|
||||||
| The first two arguments are pointers and the last argument is an immediate. | ||||||
| The result is a vector with the i1 element type. | ||||||
|
|
||||||
| Semantics: | ||||||
| """""""""" | ||||||
|
|
||||||
| ``%elementSize`` is the size of the accessed elements in bytes. | ||||||
| The intrinsic returns ``poison`` if the distance between ``%prtA`` and ``%ptrB`` | ||||||
| is smaller than ``VF * %elementsize`` and either ``%ptrA + VF * %elementSize`` | ||||||
| or ``%ptrB + VF * %elementSize`` wrap. | ||||||
| The element of the result mask is active when loading from %ptrA then storing to | ||||||
| %ptrB is safe and doesn't result in a write-after-read hazard, meaning that: | ||||||
|
||||||
| %ptrB is safe and doesn't result in a write-after-read hazard: | |
| %ptrB is safe and doesn't result in a write-after-read hazard, meaning that: |
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.
Done, thank you.
sdesmalen-arm marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
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 don't think committed is a term that is defined/used in LangRef. Would be goot to reframe this as well in general terms.
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.
Done.
sdesmalen-arm marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
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.
store-to-load forwarding hazard is not defined. Do we need this wording here?
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.
Removed.
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.
The wording for the store-to-load forwarding (hazard) behaviour cannot be removed, because it is the only distinction between this intrinsic and the .war intrinsic. i.e. The "safe" requirement is not the only behaviour that this intrinsic implements.
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've re-added the hazard wording, thanks.
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.
Can we just explain this generally (hazard language is not used in langref), does this simply say that instead a first reading and then storing a lane, it is stored first instead?
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.
Done.
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.
The reason I specifically suggested using the "introduces a hazard" terminology (along with a subsequent definition of what a hazard is) is because "safe" and "no alias" do not cover the semantics.
'no alias' can't be used because both intrinsics still return an all-active mask when their pointers fully alias.
'safe' doesn't cover the .raw intrinsic because it sets lanes to inactive when they are safe but would otherwise introduce a store-to-load forwarding hazard.
Outdated
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.
The case for ptrA == ptrB needs to be explicitly called out as 'safe' here, because it doesn't introduce any new hazards.
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.
Done.
Outdated
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.
| * ptrA == ptrB, doesn't introduce any new hazards | |
| * ptrA == ptrB (doesn't introduce any new hazards that weren't present in scalar code) |
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.
Done.
Uh oh!
There was an error while loading. Please reload this page.