This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Kirill Yukhin <kirill dot yukhin at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 6 Apr 2017 10:48:24 +0200
- Subject: Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7E2C580F98
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7E2C580F98
- References: <20170403203437.GF17461@tucnak> <CAFULd4bHKjsF-i_uhDXb0AaCw2qtV3JzQSf5wabadnX-FTft-Q@mail.gmail.com> <20170404120039.GG17461@tucnak> <CAFULd4aRw2xdbk0QtOhtuxamnb87bQvASnF5H6W-EO6PZ5GPVw@mail.gmail.com> <20170404150905.GI17461@tucnak> <CAFULd4Ym8wjf1t___oS8+4_F=8ja0-GJgWXSP8kb=yK_jciTqw@mail.gmail.com> <20170406084007.GB17461@tucnak>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Apr 06, 2017 at 10:40:07AM +0200, Jakub Jelinek wrote:
> On Thu, Apr 06, 2017 at 09:33:58AM +0200, Uros Bizjak wrote:
> > Newly introduced alternatives (x/x) and (v/v) are valid also for
> > 32-bit targets, so we have to adjust insn constraint of
> > *vec_extractv4si_0_zext and enable alternatives accordingly. After the
>
> That is true. But if we provide just the x/x and v/v alternatives in
> *vec_extractv4si_0_zext, then it will be forced to always do the zero
> extraction on the SSE registers in 32-bit mode. Is that what we want?
Also, I think we can do the zero extension even without SSE4.1,
if we have a spare SSE register (or before reload), we can use
pxor into that scratch reg and punpck* it, if we don't, we can
construct a V4SI constaint in memory with { -1, 0, 0, 0 } or so
and and with that.
Jakub