This is the mail archive of the gcc@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: GCC 4.3.0 Status Report (2008-02-14)


>>>>> Mark Mitchell writes:

Mark> However, if I understand correct, some users have probably been 
Mark> implicitly using those options because they were using "-mcpu=970", or 
Mark> otherwise specifying an AltiVec CPU.  It seems desirable in the abstract 
Mark> that this code still be binary-compatible with new -mcpu=970 code, if it 
Mark> was "plain C" code not using AltiVec vectors explicitly.  But, I don't 
Mark> know if that's technically feasible or not.

	The problem is that "plain C" code can generate Altivec
instructions in multiple ways.  Altivec is used for large, aligned block
moves.  Altivec is used for auto-vectorization, which now is enabled by
default at -O3.  GCC currently can generate incorrect code whether or not
the user explicitly enabled Altivec and whether or not the user explicitly
used Altivec instrinsics.

	The Altivec ABI does change the stack alignment.  This should not
create an incompatibility for old code, but new code may not receive the
stack properly aligned without additional dynamic alignment.  The other
issue is argument passing for GCC generic vectors, mentioned by Janis, but
that feature is documented to have "unexpected behavior" and few people
use it.

Thanks, David


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