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: ia64 vector mode support


>> Now, the first and obvious question is: Are you intending to
continue
>> your work into that direction? If so, I would probably want to stay
away
>> from doing the same thing a second time.
>
>I dunno.  Point me at the spec and I might.

There's no one except for what's in the Intel compiler documentation.
The intrinsics are intended to all be the same as for x86 (mmintrin.h,
xmmintrin.h, emmintrin.h). There's at present no pmmintrin.h, and the
stuff in emmintrin.h crashes the compiler (and is documented to not
work; I wonder why they published it at all...).

>> - Comparing with 3.4.3, the way they get passed as arguments or
>> returned has changed, mainly (as far as I can tell) because of
changes
>> in common code. Is this intentional? If not, did anyone even
notice?
>
>No, no one noticed.  Unfortunately, the ABI really isn't clear on
>how they ought to be passed either.  Curious how inconsistent 3.4
>is at treating them as fp entities...

3.4.3 passes these in fr-s and returns them in gr-s; the passing of
v4sf (and perhaps above, didn't try v4df), however, is broken in that
two registers get accessed, but only one allocated (so two consecutive
such parameters result in only three registers actually getting visited
by the called routine; didn't check how the caller behaves, yet)

>> Matching the ABI (according to which, as I'm reading it, these
should
>> be treated as HFAs),
>
>Agreed... except that there's no "funpack" instruction, so passing
>a parameter would be, at minimum,
>
>	getf.sig r2 = foo
>	;;
>	setf.s f8 = r2
>	shr r3 = r2, 32
>	;;
>	setf.s f9 = r3
>
>and I don't think anyone wants that.

Yes, that's definitely undesirable. Doing this through memory could in
some cases even be more efficient (producing smaller code, assuming the
possibly higher latency can successfully be hidden).

>> ... matching the Intel compiler (which I can compare with) ...
>
>That would probably be best.

As said in another mail, I'm waiting for them to state their position
on ABI compliance here.

Jan


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