[PATCH] Tiny predcom improvement (PR tree-optimization/59643)

Jeff Law law@redhat.com
Tue Jan 7 05:48:00 GMT 2014


On 12/31/13 12:04, Jakub Jelinek wrote:
> Hi!
>
> As written in the PR, I've been looking why is llvm 3.[34] so much faster
> on Scimark2 SOR benchmark and the reason is that it's predictive commoning
> or whatever it uses doesn't give up on the inner loop, while our predcom
> unnecessarily gives up, because there are reads that could alias the write.
>
> This simple patch improves the benchmark by 42%.  We already ignore
> unsuitable dependencies for read/read, the patch extends that for unsuitable
> dependencies for read/write by just putting the read (and anything in it's
> component) into the bad component which is ignored.  pcom doesn't optimize
> away the writes and will keep the potentially aliasing reads unmodified as
> well.  Without the patch we'd merge the two components, and as
> !determine_offset between the two DRs, it would mean the whole merged
> component would be always unsuitable and thus ignored.  With the patch
> we'll hopefully have some other reads with known offset to the write
> and can optimize that, so the patch should always either handle what
> it did before or handle perhaps some more cases.
>
> The inner loop from the (public domain) benchmark is added in the two tests,
> one runtime test and one test looking whether pcom actually optimized it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-12-31  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR tree-optimization/59643
> 	* tree-predcom.c (split_data_refs_to_components): If one dr is
> 	read and one write, determine_offset fails and the write isn't
> 	in the bad component, just put the read into the bad component.
>
> 	* gcc.dg/pr59643.c: New test.
> 	* gcc.c-torture/execute/pr59643.c: New test.
OK for the trunk.

jeff



More information about the Gcc-patches mailing list