On 12/31/2013, 2:04 PM, 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.
Congratulation, Jakub!
Scimark2 is always used by Phoronix to show how bad GCC in comparison
with LLVM. It is understandable. For some reasons phoronix is very
biased to LLVM and, I'd say, a marketing machine for LLVM.
They use very small selected benchmarks. Benchmarking is evil but I
believe more SPEC2000/SPEC2006 which use bigger real programs. With
their approach, they could use whetstone instead of Scimark but the
results would be very bad for LLVM (e.g. 64-bit code for -O3 on Haswell):
dfa:MWIPS 3705.311 -- LLVM3.3
nor:MWIPS 4587.555 -- GCC4.8
It would be nice to fix also Scimark2 LU GCC-4.8 degradation to finally
stop this nonsense from Phoronix.
