From patchwork Fri Mar 7 21:26:47 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Mi X-Patchwork-Id: 328086 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6ADC12C009E for ; Sat, 8 Mar 2014 08:26:58 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:date:message-id:subject:from:to:cc:content-type; q=dns; s=default; b=HBCTMCS61AwAZ4WJbfibg799UeY34uK8CHB3nVfICXi FQr1e79mjqO9FP1y4pT8hKOZXnMdQ0mr6WZA8nLupre0kOjsUPu9urf7cgnkZSff 7zp0zCjlninpJZWZLbjI3TFCOojt7LfdPcTChvaKuzRAtXqc3jaObWSu0L7P1Nq4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:date:message-id:subject:from:to:cc:content-type; s=default; bh=kow25Fcke2Htc6kyZwu51nQhg6A=; b=JRdFl1eTFHiLyyHBW XT8Kf1jQQ/pr1/PifYmLTGXoxCSJ89TBdvueghHKYYB1J3eyqYFnGXtBi9mt72V5 ZxA3jNQ6YO33PuT/ERCVfdSX7KyBjJW+Oc9bTL2otGA7GTNjUEvv1hxFn5EAkAUu K7VLB9J+dnfNBZBeW4hVMxSRMk= Received: (qmail 6987 invoked by alias); 7 Mar 2014 21:26:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 6973 invoked by uid 89); 7 Mar 2014 21:26:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oa0-f47.google.com Received: from mail-oa0-f47.google.com (HELO mail-oa0-f47.google.com) (209.85.219.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Mar 2014 21:26:49 +0000 Received: by mail-oa0-f47.google.com with SMTP id i11so4753178oag.6 for ; Fri, 07 Mar 2014 13:26:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=PrzOwiHneJnYFi+VOGxUoDwtgDSoZ3TWviFIwF/J30U=; b=LA3aqzF0YgQE77Z86RMvfZI4FmFCU798VxsXkn6blNYDCdd0cIxrOxLMSAZ1hHPbLR XKSRdH1SRBz+h/b0w3Gn5jY+ZeEoncTY1cleCtX2oKFVlZfLA2GBnGjBHPA7/dYgIgxt lkBa/bEuGPyF0x2GjEVxaimPpiPWslK0SecfySAuH3xXSHuF+XYmz0hS0W2ISibzheaz 0Xb16JbPsrZR8OODFtK1wJaTkjMjaIfiBPLYlgWSL8nvvjx/Beqfo+wlIumRH06xCYzr zaJlvR5fYZKwR1AGIjPiQPNoD/GlmsAoXSOMgHC8lUUQQEBqr5HsNdTjVGLrl6CXAc+b 75YA== X-Gm-Message-State: ALoCoQmfpESo2KzXV8tB8dQJ3JZkQq3MhrT1+QtJxTi8PBbD44ifwQxc9VxyYQ/Rqzt13hoGS59EQ7eXOT0AeLFOr8Y1G6ynQVvwnbsfS7c7nnpNTYNgRdCESwrnfTmVwyaznjljj7bKCeasDLbzQj1T4y549C1SVZXw8Os0v5DUh2K+IlRM7w6KxeZJnHLEhZaEkDE9lYsOHw2ZBdmv/dXkSviN1zoKKA== MIME-Version: 1.0 X-Received: by 10.182.149.168 with SMTP id ub8mr2437991obb.74.1394227607320; Fri, 07 Mar 2014 13:26:47 -0800 (PST) Received: by 10.76.180.234 with HTTP; Fri, 7 Mar 2014 13:26:47 -0800 (PST) Date: Fri, 7 Mar 2014 13:26:47 -0800 Message-ID: Subject: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call From: Wei Mi To: GCC Patches Cc: David Li , Uros Bizjak Hi, This patch is to fix the problem described here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 I follow Ian's suggestion and set ix86_tls_descriptor_calls_expanded_in_cfun in tls_global_dynamic_64_ and tls_local_dynamic_base_64_. Although 32bit doesn't have the problem, ix86_tls_descriptor_calls_expanded_in_cfun is also set for tls_global_dynamic_32 and tls_local_dynamic_base_32 to make ix86_tls_descriptor_calls_expanded_in_cfun setting consistent across 32bits and 64bits. If ix86_current_function_calls_tls_descriptor is set, we know that there is tls expanded call in current function. Update crtl->preferred_stack_boundary and crtl->stack_alignment_needed to be no less than PREFERED_STACK_ALIGNMENT at the start of ix86_compute_frame_layout. We don't do the update in legitimize_tls_address in cfgexpand stage, which is too early because according to the comments before ix86_current_function_calls_tls_descriptor, tls call may be optimized away. ix86_compute_frame_layout is the latest place to do the update. bootstrap on x86_64-linux-gnu is ok. regression test is going on. Ok for trunk if tests pass? Thanks, Wei. gcc/ChangeLog: 2014-03-07 Wei Mi * config/i386/i386.c (ix86_compute_frame_layout): Update preferred_stack_boundary when there is tls expanded call. * config/i386/i386.md: Set ix86_tls_descriptor_calls_expanded_in_cfun. gcc/testsuite/ChangeLog: 2014-03-07 Wei Mi * g++.dg/pr58066.C: New test. Index: gcc/config/i386/i386.c =================================================================== --- gcc/config/i386/i386.c (revision 208410) +++ gcc/config/i386/i386.c (working copy) @@ -9504,6 +9504,19 @@ ix86_compute_frame_layout (struct ix86_f crtl->preferred_stack_boundary = 128; crtl->stack_alignment_needed = 128; } + /* For 64-bit target, preferred_stack_boundary is never updated for call + expanded from tls descriptor. Update it here. We don't update it in + expand stage because according to the comments before + ix86_current_function_calls_tls_descriptor, tls calls may be optimized + away. */ + else if (TARGET_64BIT + && ix86_current_function_calls_tls_descriptor + && crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY) + { + crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY; + if (crtl->stack_alignment_needed < PREFERRED_STACK_BOUNDARY) + crtl->stack_alignment_needed = PREFERRED_STACK_BOUNDARY; + } gcc_assert (!size || stack_alignment_needed); gcc_assert (preferred_alignment >= STACK_BOUNDARY / BITS_PER_UNIT); Index: gcc/config/i386/i386.md =================================================================== --- gcc/config/i386/i386.md (revision 208410) +++ gcc/config/i386/i386.md (working copy) @@ -12891,7 +12891,11 @@ UNSPEC_TLS_GD)) (clobber (match_scratch:SI 4)) (clobber (match_scratch:SI 5)) - (clobber (reg:CC FLAGS_REG))])]) + (clobber (reg:CC FLAGS_REG))])] + "" +{ + ix86_tls_descriptor_calls_expanded_in_cfun = true; +}) (define_insn "*tls_global_dynamic_64_" [(set (match_operand:P 0 "register_operand" "=a") @@ -12946,7 +12950,10 @@ (const_int 0))) (unspec:P [(match_operand 1 "tls_symbolic_operand")] UNSPEC_TLS_GD)])] - "TARGET_64BIT") + "TARGET_64BIT" +{ + ix86_tls_descriptor_calls_expanded_in_cfun = true; +}) (define_insn "*tls_local_dynamic_base_32_gnu" [(set (match_operand:SI 0 "register_operand" "=a") @@ -12982,7 +12989,11 @@ UNSPEC_TLS_LD_BASE)) (clobber (match_scratch:SI 3)) (clobber (match_scratch:SI 4)) - (clobber (reg:CC FLAGS_REG))])]) + (clobber (reg:CC FLAGS_REG))])] + "" +{ + ix86_tls_descriptor_calls_expanded_in_cfun = true; +}) (define_insn "*tls_local_dynamic_base_64_" [(set (match_operand:P 0 "register_operand" "=a") @@ -13029,7 +13040,10 @@ (mem:QI (match_operand 1)) (const_int 0))) (unspec:P [(const_int 0)] UNSPEC_TLS_LD_BASE)])] - "TARGET_64BIT") + "TARGET_64BIT" +{ + ix86_tls_descriptor_calls_expanded_in_cfun = true; +}) ;; Local dynamic of a single variable is a lose. Show combine how ;; to convert that back to global dynamic. Index: gcc/testsuite/g++.dg/pr58066.C =================================================================== --- gcc/testsuite/g++.dg/pr58066.C (revision 0) +++ gcc/testsuite/g++.dg/pr58066.C (revision 0) @@ -0,0 +1,12 @@ +/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && lp64 } } } */ +/* { dg-options "-fPIC -O2 -m64" } */ + +/* Check whether the stack frame starting address of tls expanded call + in __cxa_get_globals() is 16bytes aligned. */ +static __thread char ccc; +extern "C" void* __cxa_get_globals() throw() +{ + return &ccc; +} + +/* { dg-final { scan-assembler ".cfi_def_cfa_offset 16" } } */