Date: Sat, 23 Nov 2013 22:20:14 +0000 From: Alp Toker <alp@nuanti.com> To: Dimitry Andric <dim@FreeBSD.org>, =?ISO-8859-1?Q?=22C=2E_Bergstr=F6?= =?ISO-8859-1?Q?m=22?= <cbergstrom@pathscale.com> Cc: Alexey Dokuchaev <danfe@nsu.ru>, hackers@FreeBSD.org, cfe-commits@cs.uiuc.edu Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction Message-ID: <52912A1E.5090105@nuanti.com> In-Reply-To: <A7CD3ADC-872C-40D7-B48A-C0C1A8FA885A@FreeBSD.org> References: <20131101124645.GA73456@regency.nsu.ru> <20131101154320.GA11359@regency.nsu.ru> <52742115.9010404@pathscale.com> <A7CD3ADC-872C-40D7-B48A-C0C1A8FA885A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Dimitry, I've confirmed your fix is correct. Landed in r195558. Alp. On 02/11/2013 00:07, Dimitry Andric wrote: > On 01 Nov 2013, at 22:45, C. Bergström <cbergstrom@pathscale.com> wrote: >> On 11/ 1/13 10:43 PM, Alexey Dokuchaev wrote: >>> On Fri, Nov 01, 2013 at 07:46:45PM +0700, Alexey Dokuchaev wrote: >>>> What adds to confusion, in their manual [1] Intel spells them differently >>>> themselves: first, in the table, it says: >>>> >>>> _mm_movpi64_epi64 Move MOVDQ2Q >>>> ^^^^^ >>>> >>>> Then later, when they describe what it does, it says: >>>> >>>> __m128i _mm_movpi64_pi64(__m64 a) >>>> ^^^^ >>>> Moves the 64 bits of a to the lower 64 bits of the result, zeroing the >>>> upper bits. >>> Microsoft (http://msdn.microsoft.com/en-us/library/has3d153(v=vs.90).aspx) >>> defines these two: >>> >>> _mm_movepi64_pi64 MOVDQ2Q Move >>> _mm_movpi64_epi64 MOVQ2DQ Move >>> >>> That is: >>> >>> __m64 _mm_movepi64_pi64 (__m128i a); >>> MOVDQ2Q >>> r0 := a0 ; >>> >>> __m128i _mm_movpi64_epi64 (__m64 a); >>> MOVDQ2Q >>> r0 := a0 ; r1 := 0X0 ; >>> >>> Cf. Intel's: >>> >>> _mm_movepi64_pi64 Move MOVDQ2Q >>> _mm_movpi64_epi64 Move MOVDQ2Q >>> >>> __m64 _mm_movepi64_pi64(__m128i a) >>> Returns the lower 64 bits of a as an __m64 type: R0 := a0 >>> >>> __m128i _mm_movpi64_pi64(__m64 a) >>> Moves the 64 bits of a to the lower 64 bits >>> of the result, zeroing the upper bits: R0 := a0, R1 = 0X0 >>> >>> Assuming that both documents correctly assign instructions to function >>> names (bonus clue: it also makes them symmetrical), then _mm_movpi64_pi64 >>> is indeed a typo and Clang's header is wrong, while GCC's is correct: it >>> should read _mm_movpi64_epi64(), not _mm_movpi64_pi64(). >> Why isn't this being asked on the clang or llvm mailing list? Wouldn't this impact upstream as well? > Indeed, so redirecting to the cfe-commits list. It looks like this incorrect function name has been in emmintrin.h since clang r61443 (by andersca). Basically, we need the typo fixed as follows: > > Index: tools/clang/lib/Headers/emmintrin.h > =================================================================== > --- tools/clang/lib/Headers/emmintrin.h (revision 193039) > +++ tools/clang/lib/Headers/emmintrin.h (working copy) > @@ -1366,7 +1366,7 @@ _mm_movepi64_pi64(__m128i __a) > } > > static __inline__ __m128i __attribute__((__always_inline__, __nodebug__)) > -_mm_movpi64_pi64(__m64 __a) > +_mm_movpi64_epi64(__m64 __a) > { > return (__m128i){ (long long)__a, 0 }; > } > > Is this OK? > > -Dimitry > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits -- http://www.nuanti.com the browser experts
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52912A1E.5090105>