On 13/06/16 15:48, Marc Glisse wrote:
+ /* All synthesis algorithms require shifts, so bail out early if
+ target cannot vectorize them. */
+ if (!target_has_vecop_for_code (LSHIFT_EXPR, vectype))
+ return false;
Hmm, 2 points:
* Could you use vect_supportable_shift (or equivalent) instead? This way it will work even
if a target/mode supports vector << scalar and not vector << vector.
Ok, will do.
* This means that we will refuse to vectorize x*2 as x+x, which was the goal of my patch (SPARC VIS has additions, no shift, and limited multiplications, IIRC). I guess it would be possible, as a follow-up (it doesn't have to block your
patch), not to give up in the no-shift branch, but to handle some small factors with only additions and subtractions. Or to split the emission of shifts to a function that, when shifts are not supported, emulates them with additions. Or
even emit shifts and rely on expand or vector lowering to turn them to additions (though the estimated cost might be off). Any idea on the best way to handle SPARC?
This is my first time touching the vectorizer so I don't know for sure what
would be the preferred approach.
Looks like expand_shift_1 in expmed.c already has code to expand a shift as
additions, though it's gated on rtx costs
which I suppose SPARC won't implement accurately for vector shifts since it
doesn't support them.
I suppose that code could easily be factored out to do the right thing though.
I think splitting emission of shifts into a function that synthesises them with
additions when appropriate
would be best.
Kyrill
