aboutsummaryrefslogtreecommitdiff
path: root/gcc/alias.cc
diff options
context:
space:
mode:
authorRichard Biener <rguenther@suse.de>2024-01-15 12:55:20 +0100
committerRichard Biener <rguenther@suse.de>2024-01-23 08:08:27 +0100
commita98d5130a6dcff2ed4db371e500550134777b8cf (patch)
treeacb49438fccc48092005a62035b75ed384574191 /gcc/alias.cc
parent7218f5050cb7163edae331f54ca163248ab48bfa (diff)
downloadgcc-a98d5130a6dcff2ed4db371e500550134777b8cf.zip
gcc-a98d5130a6dcff2ed4db371e500550134777b8cf.tar.gz
gcc-a98d5130a6dcff2ed4db371e500550134777b8cf.tar.bz2
rtl-optimization/113255 - base_alias_check vs. pointer difference
When the x86 backend generates code for cpymem with the rep_8byte strathegy for the 8 byte aligned main rep movq it needs to compute an adjusted pointer to the source after doing a prologue aligning the destination. It computes that via src_ptr + (dest_ptr - orig_dest_ptr) which is perfectly fine. On RTL this is then 8: r134:DI=const(`g'+0x44) 9: {r133:DI=frame:DI-0x4c;clobber flags:CC;} REG_UNUSED flags:CC 56: r129:DI=const(`g'+0x4c) 57: {r129:DI=r129:DI&0xfffffffffffffff8;clobber flags:CC;} REG_UNUSED flags:CC REG_EQUAL const(`g'+0x4c)&0xfffffffffffffff8 58: {r118:DI=r134:DI-r129:DI;clobber flags:CC;} REG_DEAD r134:DI REG_UNUSED flags:CC REG_EQUAL const(`g'+0x44)-r129:DI 59: {r119:DI=r133:DI-r118:DI;clobber flags:CC;} REG_DEAD r133:DI REG_UNUSED flags:CC but as written find_base_term happily picks the first candidate it finds for the MINUS which means it picks const(`g') rather than the correct frame:DI. This way find_base_term (but also the unfixed find_base_value used by init_alias_analysis to initialize REG_BASE_VALUE) performs pointer analysis isn't sound. The following restricts the handling of multi-operand operations to the case we know only one can be a pointer. This for example causes gcc.dg/tree-ssa/pr94969.c to miss some RTL PRE (I've opened PR113395 for this). A more drastic patch, removing base_alias_check results in only gcc.dg/guality/pr41447-1.c regressing (so testsuite coverage is bad). I've looked at gcc.dg/tree-ssa tests and mostly scheduling changes are present, the cc1plus .text size is only 230 bytes worse. With the this less drastic patch below most scheduling changes are gone. x86_64 might not the very best target to test for impact, but test coverage on other targets is unlikely to be very much better. PR rtl-optimization/113255 * alias.cc (find_base_term): Remove PLUS/MINUS handling when both operands are not CONST_INT_P. * gcc.dg/torture/pr113255.c: New testcase.
Diffstat (limited to 'gcc/alias.cc')
-rw-r--r--gcc/alias.cc28
1 files changed, 5 insertions, 23 deletions
diff --git a/gcc/alias.cc b/gcc/alias.cc
index b2ec480..6fad4b2 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -2077,31 +2077,13 @@ find_base_term (rtx x, vec<std::pair<cselib_val *,
if (tmp1 == pic_offset_table_rtx && CONSTANT_P (tmp2))
return find_base_term (tmp2, visited_vals);
- /* If either operand is known to be a pointer, then prefer it
- to determine the base term. */
- if (REG_P (tmp1) && REG_POINTER (tmp1))
- ;
- else if (REG_P (tmp2) && REG_POINTER (tmp2))
- std::swap (tmp1, tmp2);
- /* If second argument is constant which has base term, prefer it
- over variable tmp1. See PR64025. */
- else if (CONSTANT_P (tmp2) && !CONST_INT_P (tmp2))
+ if (CONST_INT_P (tmp1))
std::swap (tmp1, tmp2);
- /* Go ahead and find the base term for both operands. If either base
- term is from a pointer or is a named object or a special address
- (like an argument or stack reference), then use it for the
- base term. */
- rtx base = find_base_term (tmp1, visited_vals);
- if (base != NULL_RTX
- && ((REG_P (tmp1) && REG_POINTER (tmp1))
- || known_base_value_p (base)))
- return base;
- base = find_base_term (tmp2, visited_vals);
- if (base != NULL_RTX
- && ((REG_P (tmp2) && REG_POINTER (tmp2))
- || known_base_value_p (base)))
- return base;
+ /* We can only handle binary operators when one of the operands
+ never leads to a base value. */
+ if (CONST_INT_P (tmp2))
+ return find_base_term (tmp1, visited_vals);
/* We could not determine which of the two operands was the
base register and which was the index. So we can determine