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]

x86 MMX/SSE ABI compatibility with ICC


Early this year an attempt was made to make gcc compatible with icc.
Besides this appearantly having been a partial attempt (icc also returns
__m64 values in mm0 [and consequently doesn't ask for adding emms before
the return statement in that case], while gcc returns them through
memory just like other aggregates) I am also worried about the whole
idea here.

Since gcc has generic support for vector modes, tying the passing of
arguments/return values of these types to the modes of the types makes
it impossible to write generic (i.e. machine independent, not just
x86-sub-architecture independent) code. Thus I would instead, to become
icc compatible, see __m64 (and __m128) to become types distinguishable
from any of the vector types the modes of which they support, perhaps by
means of an i386-specific attribute or i386-specific modes. Then, the
intrinsics headers could make use of this attribute (thus making the
types as well as the intrinsics icc compatible, since the implication
really is that if one uses __m64 or __m128, then he knows what he's
doing and will take care of all the consequences [namely, using emms
when necessary]).

In any case, the generic vector types would then always be passed
through memory (or general registers if so requested by the user) in
32-bit mode (in 64-bit mode, the whole thing is a non-issue since the
ABI specifies how to pass these types), but the compiler, when
appropriate CPU support is available, could handle operations on these
types through SSE (not MMX, unless logic to automatically insert emms
where needed gets added) operations.

If that doesn't sound right, I'd be glad to get a better explanation of
rationale behind the current implementation (searching the mailing lists
I didn't find anything extensive to that sense).

Thanks, Jan


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