From patchwork Wed Jan 4 16:24:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 134292 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 549121007D6 for ; Thu, 5 Jan 2012 03:27:44 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1326299265; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Subject:Date:User-Agent:Cc:References: In-Reply-To:MIME-Version:Message-Id:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=cohgIp8uKAx0JyR1v+/7bclj64M=; b=GlnUicGt90rFbfjWAOZWo4KfOaprqyyZwlsoQ30Ik8+ndNCUF986fJS9ct3IdM cch+wD/LI4V16tkGVOOISAHfTuG+HdGW7gJyFYGOXlgj1qKtnAkgqcczF3S2N76M ZwuctqGQvyXbYs8rxiCG9cP39w2nf9b0N5CowlnmVKZrs= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Message-Id:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=l897NVrhWCALu7GtEFen2ZJ8Pn+PqMCkBVkzosV412Tri/ZUAmE4b/5cnWWVmo GhhGd5exYQdWmAFS3fe5gkZD1p3ywTZzAVmTO3aC/QnUoQGG8Bn+x4LHszy6WUS1 WGAaPOVRa7D+xtaUDAvNCZ2/R3lN9o9MM1+XfHrhKjDp0=; Received: (qmail 31359 invoked by alias); 4 Jan 2012 16:27:38 -0000 Received: (qmail 31340 invoked by uid 22791); 4 Jan 2012 16:27:34 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 16:27:21 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 2D070CB2A7E; Wed, 4 Jan 2012 17:27:21 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74IVlKMd1944; Wed, 4 Jan 2012 17:27:21 +0100 (CET) Received: from [192.168.1.2] (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id CA681CB2A77; Wed, 4 Jan 2012 17:27:20 +0100 (CET) From: Eric Botcazou To: Richard Sandiford Subject: Re: [PATCH] Fix PR tree-optimization/51315 Date: Wed, 4 Jan 2012 17:24:55 +0100 User-Agent: KMail/1.9.9 Cc: Richard Guenther , gcc-patches@gcc.gnu.org References: <201112062324.09783.ebotcazou@adacore.com> <201201031206.05214.ebotcazou@adacore.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <201201041724.55659.ebotcazou@adacore.com> 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 > OK. But passing small structures by value doesn't seem that rare -- > especially in C++ -- and it doesn't feel right to disable SRA just because > the backend likes to increase the alignment of stack vars. Agreed. > ...something like this sounds good, although you seem less than happy > with it :-) Just not very comfortable with it, as we're walking a thin line. I've attached a more "dangerous" testcase that is now optimized again (and still works). Regtested on SPARC/Solaris. Can you confirm that this fixes the pessimization in all cases (and run the C testsuite for your favorite ABI variant)? TIA. PR tree-optimization/51315 * tree-sra.c (tree_non_aligned_mem_for_access_p): New predicate. (build_accesses_from_assign): Use it instead of tree_non_aligned_mem_p. * gcc.c-torture/execute/20120104-1.c: New test. Index: tree-sra.c =================================================================== --- tree-sra.c (revision 182780) +++ tree-sra.c (working copy) @@ -1095,6 +1095,25 @@ tree_non_aligned_mem_p (tree exp, unsign return false; } +/* Return true if EXP is a memory reference less aligned than what the access + ACC would require. This is invoked only on strict-alignment targets. */ + +static bool +tree_non_aligned_mem_for_access_p (tree exp, struct access *acc) +{ + unsigned int acc_align; + + /* The alignment of the access is that of its expression. However, it may + have been artificially increased, e.g. by a local alignment promotion, + so we cap it to the alignment of the type of the base, on the grounds + that valid sub-accesses cannot be more aligned than that. */ + acc_align = get_object_alignment (acc->expr); + if (acc->base && acc_align > TYPE_ALIGN (TREE_TYPE (acc->base))) + acc_align = TYPE_ALIGN (TREE_TYPE (acc->base)); + + return tree_non_aligned_mem_p (exp, acc_align); +} + /* Scan expressions occuring in STMT, create access structures for all accesses to candidates for scalarization and remove those candidates which occur in statements or expressions that prevent them from being split apart. Return @@ -1123,8 +1142,7 @@ build_accesses_from_assign (gimple stmt) if (lacc) { lacc->grp_assignment_write = 1; - if (STRICT_ALIGNMENT - && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs))) + if (STRICT_ALIGNMENT && tree_non_aligned_mem_for_access_p (rhs, lacc)) lacc->grp_unscalarizable_region = 1; } @@ -1134,8 +1152,7 @@ build_accesses_from_assign (gimple stmt) if (should_scalarize_away_bitmap && !gimple_has_volatile_ops (stmt) && !is_gimple_reg_type (racc->type)) bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base)); - if (STRICT_ALIGNMENT - && tree_non_aligned_mem_p (lhs, get_object_alignment (rhs))) + if (STRICT_ALIGNMENT && tree_non_aligned_mem_for_access_p (lhs, racc)) racc->grp_unscalarizable_region = 1; }