diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2021-11-12 17:33:00 +0000 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2021-11-12 17:33:00 +0000 |
commit | 526e1639aa76b0a8496b0dc3a3ff2c450229544e (patch) | |
tree | 4fa1b1080f18d1e86749a97a8dfde1b9617d1bcc /gcc/ipa-modref.c | |
parent | 48c6cac9caea1dc7c5f50ad3a736f6693e74a11b (diff) | |
download | gcc-526e1639aa76b0a8496b0dc3a3ff2c450229544e.zip gcc-526e1639aa76b0a8496b0dc3a3ff2c450229544e.tar.gz gcc-526e1639aa76b0a8496b0dc3a3ff2c450229544e.tar.bz2 |
aarch64: Detect more consecutive MEMs
For tests like:
int res[2];
void
f1 (int x, int y)
{
res[0] = res[1] = x + y;
}
we generated:
add w0, w0, w1
adrp x1, .LANCHOR0
add x2, x1, :lo12:.LANCHOR0
str w0, [x1, #:lo12:.LANCHOR0]
str w0, [x2, 4]
ret
Using [x1, #:lo12:.LANCHOR0] for the first store prevented the
two stores being recognised as a pair. However, the MEM_EXPR
and MEM_OFFSET information tell us that the MEMs really are
consecutive. The peehole2 context then guarantees that the
first address is equivalent to [x2, 0].
While there: the reg_mentioned_p tests for loads were probably correct,
but seemed a bit indirect. We're matching two consecutive loads,
so the thing we need to test is that the second MEM in the original
sequence doesn't depend on the result of the first load in the
original sequence.
gcc/
* config/aarch64/aarch64.c: Include tree-dfa.h.
(aarch64_check_consecutive_mems): New function that takes MEM_EXPR
and MEM_OFFSET into account.
(aarch64_swap_ldrstr_operands): Use it.
(aarch64_operands_ok_for_ldpstp): Likewise. Check that the
address of the second memory doesn't depend on the result of
the first load.
gcc/testsuite/
* gcc.target/aarch64/stp_1.c: New test.
Diffstat (limited to 'gcc/ipa-modref.c')
0 files changed, 0 insertions, 0 deletions