aboutsummaryrefslogtreecommitdiff
path: root/gcc/ipa-modref.c
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2021-11-12 17:33:00 +0000
committerRichard Sandiford <richard.sandiford@arm.com>2021-11-12 17:33:00 +0000
commit526e1639aa76b0a8496b0dc3a3ff2c450229544e (patch)
tree4fa1b1080f18d1e86749a97a8dfde1b9617d1bcc /gcc/ipa-modref.c
parent48c6cac9caea1dc7c5f50ad3a736f6693e74a11b (diff)
downloadgcc-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