From patchwork Wed Mar 12 21:58:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Mi X-Patchwork-Id: 329719 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 89BC82C0090 for ; Thu, 13 Mar 2014 08:58:17 +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:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=iOZ4YXenqgB1cSq9n0 VbA/h/tfkdaSQ47FEK9KHrcAg/L8wnnb1z8Q/A4s9+iLScRFNXLy1KH2NrcoAIYk xu0oazSd7IdaWh/B7mFznwG7qqC8Cai28eR6OEuFvRwIXA8DrUvnaMw3ndbGoXmt ECxcckatKPQmbvHoThrzEzgQA= 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:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=0dUbV0mR9lQ+JPNLyfcUW89W 7N4=; b=JesuN2wCTnBB9+FdrcNF3/QmvNzXhu6uJ0f+9twuCiLdrED0TYKqevU/ wVRdPuUJKa/LuGzCvKVpXvXjSQRPWTs4q/hiBL19iQjaNy7y7mF2tsC7o6tJlz0m LUlvLJ53ZwnV2BvNlJYNBClNLABEAeoGYTgs1uFKieLTYJdIVkI= Received: (qmail 17152 invoked by alias); 12 Mar 2014 21:58:11 -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 17138 invoked by uid 89); 12 Mar 2014 21:58:10 -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-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 12 Mar 2014 21:58:09 +0000 Received: by mail-ob0-f175.google.com with SMTP id uy5so156704obc.20 for ; Wed, 12 Mar 2014 14:58:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w1sFz/ICEQqIM4iFO5/M2qAHQyezVO7Jjk6NE+1QX84=; b=ftkA82hA/FlZaX3U7CrQn4lB//Eu8dSO8QjEOLObhZlLx/3CgFcGJlcDKHhqMwRq+i diEeUTozTUVD5Re/fGBy3jpNRq6//X/Moguwis2qEDQIgpD50FeX/vWKF4yX9+goPdA4 yeNCC76pEO7iHzvJo01nhWBgORwblzaWVyvYv5TTHgqdduuddM0Ms7TrqjXnidVHoBE7 /07+LMoe69n9uabrJOsQoF1LzvfnFub0SYf9JUgKVrXfojCxvV7sTGiGJZ6kpOwEkCKk KsAHDW8dgTAi0WCXZyE+S9YJxkT0+YJ9gZIOHSDYs7rVRevxov6pTaWP8LuUPosXE6i5 kMLg== X-Gm-Message-State: ALoCoQmOhp3FaAtTNQYYjMiw/t567ZBfen+B3+JluJlL7fF+vMpEWs3BWWGA1oNkc4ZzkgIuujY+USDeiepZsCYCzHDCjNJ0FWv6hn48EClu/DSfeogSy3Vwzs1OPNQUswx9VhZHomyX8o2NrTeYZ3EZ9OtkrAtGGnDypveU4a1unsUMKUXKUgfJLf4WvaY9Uqyn4F0hiKbcKqhwyZ/3K+c0L3GauHyoxQ== MIME-Version: 1.0 X-Received: by 10.182.19.164 with SMTP id g4mr2781937obe.58.1394661487736; Wed, 12 Mar 2014 14:58:07 -0700 (PDT) Received: by 10.76.180.234 with HTTP; Wed, 12 Mar 2014 14:58:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 14:58:07 -0700 Message-ID: Subject: Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call From: Wei Mi To: "H.J. Lu" Cc: GCC Patches , David Li , Uros Bizjak This is the updated testcase. Thanks, Wei. On Wed, Mar 12, 2014 at 2:51 PM, Wei Mi wrote: > Oh, I see. Thanks! > > Wei. > > On Wed, Mar 12, 2014 at 2:42 PM, H.J. Lu wrote: >> On Wed, Mar 12, 2014 at 2:36 PM, Wei Mi wrote: >>> Hi H.J., >>> >>> Could you show me why you postpone the setting >>> ix86_tls_descriptor_calls_expanded_in_cfun until reload_complete and >>> use ix86_tls_descriptor_calls_expanded_in_cfun instead of >>> ix86_current_function_calls_tls_descriptor? Isn't >>> ix86_current_function_calls_tls_descriptor useful to consider the case >>> that tls call is optimized away? >>> >> >> When a tls call is optimized away, it won't survive reload. >> If it does survive reload, it isn't optimized away. Also >> checking df_regs_ever_live_p (SP_REG) isn't reliable >> when called from ix86_compute_frame_layout. >> >> -- >> H.J. =================================================================== --- testsuite/gcc.dg/pr58066.c (revision 0) +++ testsuite/gcc.dg/pr58066.c (revision 0) @@ -0,0 +1,18 @@ +/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && { ! ia32 } } } } */ +/* { dg-options "-fPIC -O2" } */ + +/* Check whether the stack frame starting addresses of tls expanded calls + in foo and goo are 16bytes aligned. */ +static __thread char ccc1; +void* foo() +{ + return &ccc1; +} + +__thread char ccc2; +void* goo() +{ + return &ccc2; +} + +/* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 16" 2 } } */