aboutsummaryrefslogtreecommitdiff
path: root/libjava/classpath/lib/java
diff options
context:
space:
mode:
authorMartin Jambor <mjambor@suse.cz>2025-04-07 13:32:09 +0200
committerMartin Jambor <jamborm@gcc.gnu.org>2025-04-07 13:32:41 +0200
commit07d243670020b339380194f6125cde87ada56148 (patch)
tree72e89ce7bd6a4f9bab2effd1c105d7f4df22035f /libjava/classpath/lib/java
parenta4abf0fb902816a2508dda5956f407fc27821d88 (diff)
downloadgcc-07d243670020b339380194f6125cde87ada56148.zip
gcc-07d243670020b339380194f6125cde87ada56148.tar.gz
gcc-07d243670020b339380194f6125cde87ada56148.tar.bz2
sra: Avoid creating TBAA hazards (PR118924)
The testcase in PR 118924, when compiled on Aarch64, contains an gimple aggregate assignment statement in between different types which are types_compatible_p but behave differently for the purposes of alias analysis. SRA replaces the statement with a series of scalar assignments which however have LHSs access chains modeled on the RHS type and so do not alias with a subsequent reads and so are DSEd. SRA clearly gets its "same_access_path" logic subtly wrong. One issue is that the same_access_path_p function probably should be implemented more along the lines of (parts of ao_compare::compare_ao_refs) instead of internally relying on operand_equal_p. That is however not the problem in the PR and so I will deal with it only later. The issue here is that even when the access path is the same, it must not be bolted on an aggregate type that does not match. This patch does that, taking just one simple function from the ao_compare::compare_ao_refs machinery and using it to detect the situation. The rest is just merging the information in between accesses of the same access group. I looked at how many times we come across such assignment during "make stage2-bubble" of GCC (configured with only c and C++ and without multilib and libsanitizers) and on an x86_64 there were 87924 such assignments (though now I realize not all of them had to be aggregate), so they do happen. The patch leads to about 5% increase of cases where we don't use an "access path" but resort to a MEM_REF (from 90209 to 95204). On an Aarch64, there were 92268 such assignments and the increase of falling back to MEM_REFs was by 4% (but from a bigger base 132983 to 107991). gcc/ChangeLog: 2025-04-04 Martin Jambor <mjambor@suse.cz> PR tree-optimization/118924 * tree-ssa-alias-compare.h (types_equal_for_same_type_for_tbaa_p): Declare. * tree-ssa-alias.cc: Include ipa-utils.h. (types_equal_for_same_type_for_tbaa_p): New public overloaded variant. * tree-sra.cc: Include tree-ssa-alias-compare.h. (create_access): Initialzie grp_same_access_path to true. (build_accesses_from_assign): Detect tbaa hazards and clear grp_same_access_path fields of involved accesses when they occur. (sort_and_splice_var_accesses): Take previous values of grp_same_access_path into account. gcc/testsuite/ChangeLog: 2025-03-25 Martin Jambor <mjambor@suse.cz> PR tree-optimization/118924 * g++.dg/tree-ssa/pr118924.C: New test.
Diffstat (limited to 'libjava/classpath/lib/java')
0 files changed, 0 insertions, 0 deletions