This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: PING^3 for PR target/17836, PR c/10735, PR c++/16882, PR rtl-optimization/17860[3.4]
- From: "Bonzini Paolo" <paolo dot bonzini at lu dot unisi dot ch>
- To: "David Edelsohn" <dje at watson dot ibm dot com>,"Paolo Bonzini" <bonzini at gnu dot org>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 22 Nov 2004 11:11:18 +0100
- Subject: RE: PING^3 for PR target/17836, PR c/10735, PR c++/16882, PR rtl-optimization/17860[3.4]
> None of your patches or responses have addressed my specific
> question about testing vector type instead of testing vector mode. Your
> patch should make the minimal correction to fix the bug: passing and
> returning synthetic vectors by memory. It does not. Your patch should
> warn about returning synthetic vectors in memory. It does not.
>
> I am testing the appended patch.
We are completely failing to communicate; none of us is exactly knowing what the other one is trying to express. Maybe some other rs6000 maintainer should step in?
*************** function_arg_boundary (enum machine_mode
*** 4794,4799 ****
--- 4812,4820 ----
return 64;
else if (ALTIVEC_VECTOR_MODE (mode))
return 128;
+ else if (type && TREE_CODE (type) == VECTOR_TYPE
+ && int_size_in_bytes (type) > 16)
+ return 128;
else
return PARM_BOUNDARY;
}
This one at least seems wrong to me. Once more: unless Altivec is on, Altivec vector types *won't have vector modes, but BLKmode*. The "else if (ALTIVEC_VECTOR_MODE (mode))" won't trigger! That's why I did
+ else if (type
+ && TREE_CODE (type) == VECTOR_TYPE
+ && (int_size_in_bytes (type) == 8
+ || int_size_in_bytes (type) == 16))
+ return 8 * int_size_in_bytes (type);
Plus, even when Altivec is on, you are only guaranteeing PARM_BOUNDARY alignment for V2DI. Is this mandated by the ABI? If it is not, it seems wrong because for example logical operations on them *can* be done with Altivec.
Paolo