From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 21:45:06 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BAAEA5C3 for ; Fri, 1 Nov 2013 21:45:06 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 917632A42 for ; Fri, 1 Nov 2013 21:45:06 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id x10so4414373pdj.9 for ; Fri, 01 Nov 2013 14:45:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P/ytO3ogZ97LwpPCw0waJ326MBLKLuWN+tdcS9mB2n8=; b=WnHyDIUlgRP5YTjWYFQoeV6//PVurps/hH37ICPcUCa9Kf6j23sLFjuEo97wK+oQ4I ftrskooWaei7poESd/r1s7tFRUiFwppy4U/XlmiQiklgdl0bXJMsEEPyeOZ+gWiVNmIT +7IDzk3UV/CUDWU16ENVA23rZxj/5SM9XmtJ6UC0a89t0nO61WVYQr7p6w56w47V5xym ukcHj1Hlux3gkVLiQrR4fIkYEyEtM6bVFRprHmaSm1RuOdcR9p2PfnDC3V7X1PUidyTq Lh9CkoX0cs61qP6G4G6/2X/lzMN4RZBezJasSYtFxi4filFV8wdlY0ok4Y2qpf+Azzp3 dDlQ== X-Gm-Message-State: ALoCoQl8kzCM8TzZqrONkEYPlbjZYXQdZSFZSs16B9CIFGYlrnbrT09Bp9QrLaZcRaQ55s+HYFsw X-Received: by 10.68.110.196 with SMTP id ic4mr5105826pbb.84.1383342300494; Fri, 01 Nov 2013 14:45:00 -0700 (PDT) Received: from [192.168.1.38] (ppp-115-87-127-47.revip4.asianet.co.th. [115.87.127.47]) by mx.google.com with ESMTPSA id nj9sm12881036pbc.13.2013.11.01.14.44.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 14:44:59 -0700 (PDT) Message-ID: <52742115.9010404@pathscale.com> Date: Sat, 02 Nov 2013 04:45:57 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130802 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexey Dokuchaev Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction References: <20131101124645.GA73456@regency.nsu.ru> <20131101154320.GA11359@regency.nsu.ru> In-Reply-To: <20131101154320.GA11359@regency.nsu.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 21:45:06 -0000 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?