This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add MULT_HIGHPART_EXPR
On Thu, Jun 28, 2012 at 6:44 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jun 28, 2012 at 8:57 AM, Richard Henderson <rth@redhat.com> wrote:
>> On 2012-06-28 07:05, Jakub Jelinek wrote:
>>> Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems
>>> to pessimize the generated code for gcc.dg/vect/pr51581-3.c
>>> testcase (at least with -O3 -mavx) compared to when the hooks aren't
>>> present, because i?86 has more natural support for widen mult lo/hi
>>> compoared to widen mult even/odd, but I assume that on powerpc it is the
>>> other way around. ?So, how should I find out if both VEC_WIDEN_MULT_*_EXPR
>>> and builtin_mul_widen_* are possible for the particular vectype which one
>>> will be cheaper?
>>
>> I would assume that if the builtin exists, then it is cheaper.
>>
>> I disagree about "x86 has more natural support for hi/lo". ?The basic sse2 multiplication is even. ?One shift per input is needed to generate odd. ?On the other hand, one interleave per input is required for both hi/lo. ?So 4 setup insns for hi/lo, and 2 setup insns for even/odd. ?And on top of all that, XOP includes multiply odd at least for signed V4SI.
>>
>> I'll have a look at the test case you mention while I re-look at the patches...
>>
>
> The upper 128-bit of 256-bit AVX instructions aren't a good fit with the
> current vectorizer infrastructure.
Indeed - the lack of cross-sub-128bit-word operations makes it very much
expensive for some vectorizations. Initially we added the patterns for
vectorization of the hi/lo and interleave stuff because we didn't want
regressions
for vectorizing with 256bit vectors vs. 128bit vectors in the
vectorizer testsuite.
But now as we have support for vectorizing with both sizes we could consider
not advertising the really not existing intstructions for 256bit vectors. Or at
least properly model their cost.
Richard.
>
> --
> H.J.