From patchwork Mon Sep 20 17:04:18 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 65227 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]) by ozlabs.org (Postfix) with SMTP id 11555B70CB for ; Tue, 21 Sep 2010 03:03:28 +1000 (EST) Received: (qmail 29426 invoked by alias); 20 Sep 2010 17:03:24 -0000 Received: (qmail 29417 invoked by uid 22791); 20 Sep 2010 17:03:23 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Sep 2010 17:03:14 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8KH3DnW021652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Sep 2010 13:03:13 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8KH3CtD005529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Sep 2010 13:03:12 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id o8KH4IsF004032; Mon, 20 Sep 2010 19:04:18 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id o8KH4Ipk004030; Mon, 20 Sep 2010 19:04:18 +0200 Date: Mon, 20 Sep 2010 19:04:18 +0200 From: Jakub Jelinek To: Richard Henderson Cc: "H.J. Lu" , gcc-patches@gcc.gnu.org Subject: Re: PATCH: PR middle-end/45678: [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse Message-ID: <20100920170418.GO1269@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20100917165833.GA17163@intel.com> <4C93A958.6000502@redhat.com> <20100917181519.GE1269@tyan-ft48-01.lab.bos.redhat.com> <20100917214028.GF1269@tyan-ft48-01.lab.bos.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20100917214028.GF1269@tyan-ft48-01.lab.bos.redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes 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 On Fri, Sep 17, 2010 at 11:40:28PM +0200, Jakub Jelinek wrote: > On Fri, Sep 17, 2010 at 02:31:35PM -0700, H.J. Lu wrote: > > > Using stack offset for local variable alignment is a bad idea. My patch > > > caused: > > It isn't a bad idea, as long as the base of the stack slots is going to be > as aligned as the code expects. Then it is a nice optimization, which you > are killing in your patch. All that is IMHO needed is to be a little bit > more conservative in the estimations. Haven't tested any of the > possibilities I've listed, but I bet all of them would fix > > > > > > FAIL: gcc.target/i386/incoming-9.c scan-assembler-not andl[\\t > > > ]*\\$-16,[\\t ]*%esp > > this. Here is a fix for that. On !SUPPORTS_STACK_ALIGNMENT targets STACK_BOUNDARY == PREFERRED_STACK_BOUNDARY == crtl->max_used_stack_slot_alignment so it doesn't make a difference, on the rest of targets usually get_decl_align_unit will be called on local vars before first expand_one_stack_var_at will be called, so in most cases it will be as big as can be safely assumed. Doing MAX (crtl->max_used_stack_slot_alignment, STACK_BOUNDARY) wouldn't make sense, as crtl->max_used_stack_slot_alignment is initialized to STACK_BOUNDARY at the start of expansion and only incremented afterwards during expansion (but never incremented to more than MAX_SUPPORTED_STACK_ALIGNMENT). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.5/4.4? 2010-09-20 Jakub Jelinek PR target/44542 * cfgexpand.c (expand_one_stack_var_at): Use crtl->max_used_stack_slot_alignment as max_align, instead of maximum of that and PREFERRED_STACK_BOUNDARY. Jakub --- gcc/cfgexpand.c.jj 2010-09-18 19:50:56.000000000 +0200 +++ gcc/cfgexpand.c 2010-09-20 16:46:52.124526071 +0200 @@ -738,8 +738,7 @@ expand_one_stack_var_at (tree decl, HOST offset -= frame_phase; align = offset & -offset; align *= BITS_PER_UNIT; - max_align = MAX (crtl->max_used_stack_slot_alignment, - PREFERRED_STACK_BOUNDARY); + max_align = crtl->max_used_stack_slot_alignment; if (align == 0 || align > max_align) align = max_align;