https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93434
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-8 branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:50c7f76eb30041a9b219cd6535c8c09583cc052b commit r8-10059-g50c7f76eb30041a9b219cd6535c8c09583cc052b Author: Richard Sandiford <richard.sandif...@arm.com> Date: Mon Jan 27 19:37:55 2020 +0000 predcom: Fix invalid store-store commoning [PR93434] predcom has the following code to stop one rogue load from interfering with other store-load opportunities: /* If A is read and B write or vice versa and there is unsuitable dependence, instead of merging both components into a component that will certainly not pass suitable_component_p, just put the read into bad component, perhaps at least the write together with all the other data refs in it's component will be optimizable. */ But when store-store commoning was added later, this had the effect of ignoring loads that occur between two candidate stores. There is code further up to handle loads and stores with unknown dependences: /* Don't do store elimination if there is any unknown dependence for any store data reference. */ if ((DR_IS_WRITE (dra) || DR_IS_WRITE (drb)) && (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know || DDR_NUM_DIST_VECTS (ddr) == 0)) eliminate_store_p = false; But the store-load code above skips loads for *known* dependences if (a) the load has already been marked "bad" or (b) the data-ref machinery knows the dependence distance, but determine_offsets can't handle the combination. (a) happens to be the problem in the testcase, but a different sequence could have given (b) instead. We have writes to individual fields of a structure and reads from the whole structure. Since determine_offsets requires the types to be the same, it returns false for each such read/write combination. This patch records which components have had loads removed and prevents store-store commoning for them. It's a bit too pessimistic, since there shouldn't be a problem if a "bad" load dominates all stores in a component. But (a) we can't AFAIK use pcom_stmt_dominates_stmt_p here and (b) the handling for that case would probably need to be removed again if we handled more exotic cases in future. 2020-02-25 Richard Sandiford <richard.sandif...@arm.com> gcc/ Backport from mainline 2020-01-28 Richard Sandiford <richard.sandif...@arm.com> PR tree-optimization/93434 * tree-predcom.c (split_data_refs_to_components): Record which components have had aliasing loads removed. Prevent store-store commoning for all such components. gcc/testsuite/ PR tree-optimization/93434 * gcc.c-torture/execute/pr93434.c: New test.
