From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20946 invoked by alias); 13 Mar 2012 01:21:02 -0000 Received: (qmail 20933 invoked by uid 22791); 13 Mar 2012 01:21:01 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_OV,TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Mar 2012 01:20:47 +0000 Received: by yhjj56 with SMTP id j56so13408yhj.20 for ; Mon, 12 Mar 2012 18:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.66 with SMTP id m2mr3195111qct.96.1331601647110; Mon, 12 Mar 2012 18:20:47 -0700 (PDT) Received: by 10.229.89.137 with HTTP; Mon, 12 Mar 2012 18:20:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 01:21:00 -0000 Message-ID: Subject: Re: PATCH: Properly generate X32 IE sequence From: "H.J. Lu" To: Uros Bizjak Cc: gcc-patches@gcc.gnu.org, Richard Henderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00883.txt.bz2 On Mon, Mar 12, 2012 at 3:35 PM, H.J. Lu wrote: > On Mon, Mar 12, 2012 at 12:39 PM, Uros Bizjak wrote: >> On Sun, Mar 11, 2012 at 10:24 PM, H.J. Lu wrote: >> >>> Here is the patch which is equivalent to clearing MASK_TLS_DIRECT_SEG_R= EFS >>> when Pmode !=3D word_mode. =A0We need to keep >>> >>> =A0 =A0 =A0 =A0 =A0else if (Pmode =3D=3D SImode) >>> =A0 =A0 =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Always generate >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0movl %fs:0, %reg32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addl xgottpoff(%rip), %r= eg32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to support linker IE->LE optimization a= nd avoid >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fs:(%reg32) as memory operand. =A0*/ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0dest =3D gen_reg_rtx (Pmode); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0emit_insn (gen_tls_initial_exec_x32 (dest, x= )); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0return dest; >>> =A0 =A0 =A0 =A0 =A0 =A0} >>> >>> to support linker IE->LE optimization. =A0TARGET_TLS_DIRECT_SEG_REFS on= ly affects >>> TLS LE access and fs:(%reg) is only generated by combine. >>> >>> So the main impact of disabling TARGET_TLS_DIRECT_SEG_REFS is to disable >>> fs:immediate memory operand for TLS LE access, which doesn't have any p= roblems >>> to begin with. >>> >>> I would prefer to keep TARGET_TLS_DIRECT_SEG_REFS and disable only >>> fs:(%reg), which is generated by combine. >> >> Please try attached patch. =A0It introduces TARGET_TLS_INDIRECT_SEG_REFS >> to block only indirect seg references. >> >> Uros. > > I am testing it. > There is no regression. BTW, this x32 TLS IE optimization: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00714.html is still useful. For [hjl@gnu-6 tls]$ cat ie2.i extern __thread long long int x; extern long long int y; void ie2 (void) { x =3D y; } [hjl@gnu-6 tls]$ my patch turns ie2: .LFB0: .cfi_startproc movq y(%rip), %rdx # 6 *movdi_internal_rex64/2 [length =3D 7] movl %fs:0, %eax # 5 tls_initial_exec_x32 [length =3D 16] addl x@gottpoff(%rip), %eax movq %rdx, (%eax) # 7 *movdi_internal_rex64/4 [length =3D 3] ret # 14 simple_return_internal [length =3D 1] .cfi_endproc into ie2: .LFB0: .cfi_startproc movq y(%rip), %rax # 6 *movdi_internal_rex64/2 [length =3D 7] movq x@gottpoff(%rip), %rdx # 7 *tls_initial_exec_x32_store [length =3D 16] movq %rax, %fs:(%rdx) ret # 14 simple_return_internal [length =3D 1] .cfi_endproc --=20 H.J.