This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][vectorizer][2/2] PR 65951: Hook up mult synthesis logic into vectorisation of mult-by-constant
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 13 Jun 2016 16:48:28 +0200 (CEST)
- Subject: Re: [PATCH][vectorizer][2/2] PR 65951: Hook up mult synthesis logic into vectorisation of mult-by-constant
- Authentication-results: sourceware.org; auth=none
- References: <575EA5BA dot 9020605 at foss dot arm dot com>
+ /* 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.
* 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?
--
Marc Glisse