predcom: Fix invalid store-store commoning [PR93434]
authorRichard Sandiford <richard.sandiford@arm.com>
Mon, 27 Jan 2020 19:37:55 +0000 (19:37 +0000)
committerRichard Sandiford <richard.sandiford@arm.com>
Tue, 28 Jan 2020 10:47:43 +0000 (10:47 +0000)
commit6cedf5d8e23c862db147e71d5767ca57e6b4f433
treef55dd90d0100ed5e72c8875c6ad5094e65420787
parent3aa64a0f08664a4b0094352aa11f877fa2bd4c37
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-01-28  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
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.
gcc/ChangeLog
gcc/testsuite/ChangeLog
gcc/testsuite/gcc.c-torture/execute/pr93434.c [new file with mode: 0644]
gcc/tree-predcom.c