This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [i386] access subvectors
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org, Uros Bizjak <ubizjak at gmail dot com>
- Date: Thu, 3 May 2012 10:25:10 +0200
- Subject: Re: [i386] access subvectors
- References: <alpine.DEB.2.02.1205022247440.2504@laptop-mg.saclay.inria.fr>
On Wed, May 2, 2012 at 11:46 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> Hello,
>
> I definitely don't expect the attached patch to be accepted, but I would
> like some advice on the direction to go, and a patch that passes the
> testsuite and does the optimization I want on a couple testcases seems like
> it may help start the conversation. This is the first time I even look at
> .md files...
>
> The goal is to optimize: v8sf x; v4sf y=*(v4sf*)&x; so the compiler doesn't
> copy x to memory (yes, I know there is an intrinsic to do that).
>
> If I understood Richard Guenther's comment in the PR, it can be optimized in
> the back-end.
Expand simply uses a subreg to access the lower half. I suppose we miss
some simplify_rtx/combine logic that ends up using a vec_select (can
that even be used to select the lower/upper half?). Uros? We want
movq %ymm0, %xmm1 (or rather simply use xmm0 in consumers) here.
Richard.
> The only way I found to place this kind of transformation is
> with define_peephole2. And I couldn't figure out how to test if 2 memory
> operands correspond to the same address, with different types (so match_dup
> is unhappy), and for some reason the XEXP(*,0) comparison said yes on my
> test and no when using an unrelated piece of memory, but it looks like a
> nonsense test that is just lucky on a couple trivial examples.
>
> Any help?
>
>
> 2012-05-02 ?Marc Glisse ?<marc.glisse@inria.fr>
> ? ? ? ?PR target/53101
>
> gcc/
> ? ? ? ?* config/i386/sse.md: New peephole2 for subvectors.
>
> gcc/testsuite/
> ? ? ? ?* gcc.target/i386/pr53101.c: New test.
>
>
> --
> Marc Glisse