AArch64: Try to move 32-bit stores together for pairing #9674
Conversation
We sometimes see sequences of vasm operations like this: ldimml ..., %x storel %x, [%sp - 0x80] ldimml ..., %y storel %y, [%sp - 0x7c] The stores are actually contiguous in memory and if they were next to each other they would be paired up into a storepairl. This patch looks for such patterns and rewrites them as ldimml ..., %x ldimml ..., %y storepairl %x, %y, [%sp - 0x80]
|
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this in D87553158. (Because this pull request was imported automatically, there will not be any future comments.) |
| // store x0, [sp - 0x7c] | ||
| // In this example we can't push the first store next to the second due to the | ||
| // reuse of x0. | ||
| if (!st1.s.isVirt()) return false; |
There was a problem hiding this comment.
I just realised there might be a subtle (and unlikely) bug here because a virtual register (Vreg) does not tell you anything about the class of the register, i.e. integer or floating point? So the first store in the pair could in fact be storing out a FP value, while the second store could be of an integer value. The lowering of storepair currently assumes both registers are GPs.
I think the solution here is to find the definition of register st1.s and make sure it's also come from a ldimml.
|
@david-arm has updated the pull request. You must reimport the pull request before landing. |
2 participants
We sometimes see sequences of vasm operations like this:
ldimml ..., %x
storel %x, [%sp - 0x80]
ldimml ..., %y
storel %y, [%sp - 0x7c]
The stores are actually contiguous in memory and if they were next to each other they would be paired up into a storepairl. This patch looks for such patterns and rewrites them as
ldimml ..., %x
ldimml ..., %y
storepairl %x, %y, [%sp - 0x80]