Re: GCC 4.3.0 Status Report (2008-02-14)

[Mark Mitchell <mark at codesourcery dot com>]

David Edelsohn wrote:
> > > > > > 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. 

I was afraid of that.

> 	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.

So, if we wanted to make this interoperate better, we'd have to 
introduce dynamic stack alignment in every externally visible function, 
thereby penalizing the average user who isn't trying to support linking 
with legacy code.  Right?

I suppose that another solution would be to have the linker generate 
stubs.  Let the new code just use the standard ABI, but mark the 
functions in some way to that the linker could generate stubs for calls 
from legacy code.  The stubs would align the stack and then call the 
real function.  That would avoid penalizing the new code, but still 
preserve compatibility.

If you think that's a good idea, though, that doesn't stand in the way 
of the plan you and Janis have presented -- it's a follow-on idea that 
could be implemented if there's enough demand.  That's good.

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713