This is the mail archive of the 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: PING^3 for PR target/17836, PR c/10735, PR c++/16882, PR rtl-optimization/17860[3.4]

>>>>> Bonzini Paolo writes:

Paolo> *************** function_arg_boundary (enum machine_mode
Paolo> *** 4794,4799 ****
Paolo> --- 4812,4820 ----
Paolo> return 64;
Paolo> else if (ALTIVEC_VECTOR_MODE (mode))
Paolo> return 128;
Paolo> +   else if (type && TREE_CODE (type) == VECTOR_TYPE
Paolo> +          && int_size_in_bytes (type) > 16)
Paolo> +     return 128;
Paolo> else
Paolo> return PARM_BOUNDARY;
Paolo> }

Paolo> 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 
	Why should parameters have stricter alignment if there is no SIMD

Paolo> +  else if (type
Paolo> +    && TREE_CODE (type) == VECTOR_TYPE
Paolo> +    && (int_size_in_bytes (type) == 8
Paolo> +        || int_size_in_bytes (type) == 16))
Paolo> +    return 8 * int_size_in_bytes (type);

Paolo> 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. 
	Also, while V2DI can be packed into an Altivec register and one
can apply a logical op, Altivec operations are not defined for those
types -- it is not part of the ABI.  There is no defined way to load and
store V2DI.  If you pun the type to load and store, you equally can pun
the type to perform logical ops.


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