On 06/17/2016 04:41 AM, Ilya Enkovich wrote:
1. You've got 3 modes for epilogue vectorization. Is this an artifact of
not really having good heuristics yet for which mode to apply to a
particular loop at this time?
2. Similarly for cost models.
All three modes are profitable in different situations. Profitable mode depends
on a loop structure and target capabilities. Ultimate goal is to have all three
modes enabled by default. I can't state current heuristics are good enough
for all cases and targets and therefore don't enable epilogues vectorization
by default for now. This is to be measured, analyzed and tuned in
time for GCC 7.1.
I add cost model simply to have an ability to force epilogue vectorization for
stability testing (force some mode of epilogue vectorization and check nothing
fails) and performance testing/tuning (try to find cases where we may benefit
from epilogue vectorization but don't due to bad cost model). Also I don't
want to force epilogue vectorization for all loops for which vectorization is
forced using unlimited cost model because that may hurt performance for
simd loops.
Thanks. That overview helps a lot.
We've done something similar to what you're doing with cost models for
testing in the scheduler and other places in the past. The costing
models seem more geared towards us as developers rather than users. you
might consider keep those as local changes and not documenting them.
Understood completely on the modes.
Currently I have numbers collected on various suites for KNL machine. Masking
mode (-ftree-vectorize-epilogues=mask) shows not bad results (dynamic
cost model,
-Ofast -flto -funroll-loops). I don't see significant losses and there are few
significant gains. For combine and nomask modes the result is not good enough
yet - there are several significant performance losses. My guess is that
current threshold for combine is way too high and for nomask variant we better
choose the smallest vector size for epilogues instead of the next available
(use zmm for body and xmm for epilogue instead of zmmm for body and ymm for
epilogue).
ICC shows better results in these modes which makes me believe we can tune them
as well. Overall nomask mode shows worse results comparing to options with
masking which is quite expected for KNL.
Unfortunately some big gains demonstrated by ICC are not reproducible
using GCC because we originally can't vectorize required hot loops. E.g. on
200.sixtrack GCC has nothing and ICC has ~40% for all three modes.
I hadn't pondered that case. Certainly if GCC isn't vectorizing as
much, we're not going to have as many opportunities for optimizing the
vec-tails.
Given the results with ICC, we're probably best off keeping all 3 modes
and working to get them tuned correctly.
I don't have the whole statistics for Haswell but synthetic tests show the
situation is really different from KNL. Even for the 'perfect' iterations count
number (VF * 2 - 1) scalar version of epilogue shows the same result as a masked
one. It means ratio of vector code performance vs. scalar code performance is
not as high as for KNL (KNL is more vector oriented and has weaker
scalar performance,
double vector size also matters here) and masking cost is higher for Haswell.
We still focus on AVX-512 targets more because of their rich masking
capabilities and wider vector.
Understood.
Jeff
