From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75532 invoked by alias); 12 Aug 2019 09:20:59 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 75268 invoked by uid 89); 12 Aug 2019 09:20:59 -0000 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 Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Aug 2019 09:20:56 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id x7C9Kshw098119 for ; Mon, 12 Aug 2019 02:20:54 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpd6LllAX; Mon Aug 12 02:20:47 2019 Subject: Re: Inefficient use of 64-bit addresses in Clang To: cygwin@cygwin.com References: <578eb489-9391-9009-82ad-676eeb4c1c92@agner.org> From: Mark Geisert Message-ID: <92abca5a-58f7-7d34-caab-73dcd36b31fb@maxrnd.com> Date: Mon, 12 Aug 2019 09:20:00 -0000 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 X-SW-Source: 2019-08/txt/msg00143.txt.bz2 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