X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=mBYjS6jnYBI6kJsX kS/nCymO4z2VwjPh43PQz7eZp3MD67+ruvaBwlmA7yh5sgSP323+DMTHZIrhYiO6 pK6By1/3TU27fVwdGjhsXs+LAWB4CUFVnYQ8v6tC05fDsbssLiym+c5/NmQ9xart ke7e/FfVoL1e1GA+PWq9y9Afjac= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=DNCIaXmz0IafMO5pEKWfAY eowaA=; b=NynnemOqsAhMiimULBYs/B5Z0XjWwrQYWSOmExvYHQbdzGrVwcD9lC qEemCgSafvAP1F9fTGwOC02RrHJeOIWw9LBPnCBpEO14bsp0s/RfiIvbcaPnRnN8 K/zzayYPhhtISWmwNXxpXn7e6bj9L4qhgkrRw1rwjOrDH7BSoJkkI= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=Assembly, busy, H*UA:Firefox, Clang X-HELO: m0.truegem.net Subject: Re: Inefficient use of 64-bit addresses in Clang To: cygwin AT cygwin DOT com References: <578eb489-9391-9009-82ad-676eeb4c1c92 AT agner DOT org> From: Mark Geisert Message-ID: <92abca5a-58f7-7d34-caab-73dcd36b31fb@maxrnd.com> Date: Mon, 12 Aug 2019 02:20:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <578eb489-9391-9009-82ad-676eeb4c1c92@agner.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Note-from-DJ: This may be spam Agner Fog wrote: > Clang is using 64-bit absolute addresses when accessing static data in 64-bit > mode. This is inefficient because it requires an extra 10-bytes long instruction > for loading an address into a register every time it needs to access static > data. All other compilers use relative addresses. > > Example: > >> #include >> >> __m128d test (__m128d a) { >>     __m128d b = _mm_add_pd(a, _mm_set1_pd(1.5)); >>     __m128d c = _mm_mul_pd(b, _mm_set1_pd(2.5)); >>     return c; >> } > > Assembly output: > >> .LCPI0_0: >>     .quad    4609434218613702656     # double 1.5 >>     .quad    4609434218613702656     # double 1.5 >> .LCPI0_1: >>     .quad    4612811918334230528     # double 2.5 >>     .quad    4612811918334230528     # double 2.5 >>     .text >>     .globl    _Z4testDv2_d >>     .p2align    4, 0x90 >> _Z4testDv2_d:                           # @_Z4testDv2_d >> # BB#0: >>     vmovapd    (%rcx), %xmm0 >>     movabsq    $.LCPI0_0, %rax >>     vaddpd    (%rax), %xmm0, %xmm0 >>     movabsq    $.LCPI0_1, %rax >>     vmulpd    (%rax), %xmm0, %xmm0 >>     retq > > Linux Clang uses 32-bit relative addresses: > >>     vaddpd    .LCPI0_0(%rip), %xmm0, %xmm0 >>     vmulpd    .LCPI0_1(%rip), %xmm0, %xmm0 >>     retq This kind of bug report should probably go to the Clang bugtracker at https://bugs.llvm.org . On that page you could enter "clang cygwin" in the Quick Search field and see what known issues there are. Clang is packaged for Cygwin by a very industrious and busy maintainer, but no development on Clang is being done here (to my knowledge). So something like a Cygwin packaging error that breaks Clang on Cygwin would be on-topic for this list, but a problem at code generation level should go to the Clang developers. ..mark -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple