This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [i386] access subvectors


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]