Re: SPEC 456.hmmer vectorization question

[Steve Ellcey <sellcey at caviumnetworks dot com>]

On Tue, 2017-03-07 at 14:45 +0100, Michael Matz wrote:
> Hi Steve,
> 
> On Mon, 6 Mar 2017, Steve Ellcey wrote:
> 
> > 
> > I was looking at the spec 456.hmmer benchmark and this email string
> > from Jeff Law and Micheal Matz:
> > 
> >   https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01970.html
> > 
> > and was wondering if anyone was looking at what more it would take
> > for GCC to vectorize the loop in P7Viterbi.

> It takes what I wrote in there.  There are two important things that need 
> to happen to get the best performance (at least from an analysis I did in 
> 2011, but nothing material should have changed since then):

I guess I was hoping that some progress had been made since then, but
it sounds like it hasn't.

> (1) loop distribution to make some memory streams vectorizable (and leave 
>     the others in non-vectorized form).
> (1a) loop splitting based on conditional (to remove the k
> (2) a predictive commoning (or loop carried store reuse) on the dc[] 
>     stream
> 
> None of these is valid if the loop streams can't be disambiguated, and as 
> this is C only adding explicit restrict qualifiers would give you that, or 
> runtime disambiguation, like ICC is doing, that's part (0).

So it sounds like the loop would have to be split up using runtime
disambiguation before we could do any of the optimizations.  Would that
check and split be something that could or should be done using the
graphite framework or would it be a seperate pass done before the
graphite phase is called?  I am not sure how one would determine what
loops would be worth splitting and which ones would not during such a
phase.

Steve Ellcey
sellcey@cavium.com