This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] optabs and tree-codes for vector operations
On Wed, Aug 25, 2004 at 05:43:49PM +0300, Dorit Naishlos wrote:
> I hope it would be OK to introduce a new tree-code for this
> purpose (LOADU_EXPR?) temporarily until we figure out how to do that.
You've forgotten about stores again. I think the level of effort
involved in propagating new tree codes that can affect stores is
about the same as fixing the alignment propagation problem, and is
less useful generally.
> When 'magic' is a vector (of indices) then it has exactly the same
> functionality as the VEC_PERM that we are going to introduce.
Yes, but this is true *only* of Altivec.
> Maybe if we gave it a more general
> name (VEC_EXTRACT? VEC_PAIR_EXTRACT? VEC_PAIR_SELECT? VEC_JOIN?
> VEC_SEL_JOIN?) we could reuse the same tree-code for the different
> purposes, including unaligned stores and loads.
You can't do that without exposing what "magic" means.
As for VEC_PERM generally, please have a look at
http://www.freescale.com/files/32bit/doc/user_guide/EREF.pdf
Page 8-232 is the "evsel" instruction. Note that it does allow
arbitrary permutation of a V2SI/V2SF, but also note the form of
the selector -- a condition code register, not a vector.
And note that no one else implements anything like VEC_PERM with
non-constant arguments. So while I agree that VEC_PERM is nice
and general, I say it's *too* general. And the fact that the
full generality is present on one system -- one that IBM cares
about ;-) -- is blinding you to what is or isn't possible with
other systems.
> 2. load from a "floor aligned" address ("LOADFLOOR")
> optab (new): load_floor_optab
> tree (new): MODIFY_EXPR (z, ALIGN_INDIRECT_REF(ptr_ref))
>
> 3. load from an arbitrary address ("LOADU")
> optab (new): loadu_optab
> tree: option1 (preferred): MODIFY_EXPR (z,ref),
> in which ref has alignment info (ala dannyb)
> option2 (new tree, until above is supported): LOADU_EXPR (z,ref)
>
> example: LOADU = ldl,ldr,or[mips]/ movdqu[sse]/
> ldqu,ldqu,extql,extqh,or[alpha]/ lvx,lvx,lvsr,vperm[vmx]
Again, it's not just loads. It's stores as well.
> 4. join/merge the relevant data from two vectors, given the address of the
> requested data ("JOIN")
> option1: optab (new): realign_load_optab
> tree (new): REALIGN_LOAD_EXPR (x,y,magic)
> option2: reuse vec_perm_optab, VEC_PERM_EXPR (x,y,magic) (or however
> we're going to call it).
We need a different operation for stores here. The realignment
based on the address is reversed.
> 4.1. "JOIN_CST": optab (new): realign_cst_load_optab?
> example: extql,extqh,or[alpha]/ lvsl(addr),vperm[vmx]
>
> 4.2. "JOIN_ARBIRARY": optab (new): realign_load_optab?
> example: lvsr(-addr),vperm[vmx]
What are you planning to do with these? Apart from being able
to issue "vperm" from them, what semantics do you want?
r~