From patchwork Fri Nov 5 17:41:54 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 70272 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 1AC6AB70A5 for ; Sat, 6 Nov 2010 04:42:05 +1100 (EST) Received: (qmail 15346 invoked by alias); 5 Nov 2010 17:42:03 -0000 Received: (qmail 15334 invoked by uid 22791); 5 Nov 2010 17:42:02 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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; Fri, 05 Nov 2010 17:41:58 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oA5HfupM026930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Nov 2010 13:41:56 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oA5Hft9C003748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Nov 2010 13:41:56 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id oA5Hftbn004274 for ; Fri, 5 Nov 2010 18:41:55 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id oA5HfsQx004272 for gcc-patches@gcc.gnu.org; Fri, 5 Nov 2010 18:41:54 +0100 Date: Fri, 5 Nov 2010 18:41:54 +0100 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Subject: [PATCH] Improve MEM_REF expansion (PR target/45670) Message-ID: <20101105174154.GJ29412@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi! Without EXPAND_SUM op0 is often not as complex as some targets (e.g. i?86/x86_64) can handle in memory addresses and in some cases, as in the testcase below, if we expand it wrong way we aren't able to fix it up afterwards. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2010-11-05 Jakub Jelinek PR target/45670 * expr.c (expand_expr_real_1) : Use EXPAND_SUM instead of EXPAND_NORMAL for base expansion. * gcc.target/i386/pr45670.c: New test. Jakub --- gcc/expr.c.jj 2010-11-01 09:07:22.000000000 +0100 +++ gcc/expr.c 2010-11-05 11:19:21.000000000 +0100 @@ -8712,7 +8712,7 @@ expand_expr_real_1 (tree exp, rtx target } align = MAX (TYPE_ALIGN (TREE_TYPE (exp)), get_object_alignment (exp, BIGGEST_ALIGNMENT)); - op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL); + op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_SUM); op0 = convert_memory_address_addr_space (address_mode, op0, as); if (!integer_zerop (TREE_OPERAND (exp, 1))) { --- gcc/testsuite/gcc.target/i386/pr45670.c.jj 2010-11-05 11:42:22.000000000 +0100 +++ gcc/testsuite/gcc.target/i386/pr45670.c 2010-11-05 11:41:28.000000000 +0100 @@ -0,0 +1,23 @@ +/* PR target/45670 */ +/* { dg-do compile } */ +/* { dg-options "-Os -mtune=generic" } */ + +struct S +{ + float *buf; + int size; +}; + +void +foo (struct S *s) +{ + int i; + for (i = 0; i < s->size; ++i) + s->buf[i] = 0; +} + +/* Ensure we don't generate + lea (reg1,4),reg2; add (reg3),reg2; movl $0, (reg2) + instead of smaller + mov (reg3),reg2; movl $0, (reg2,reg1,4) */ +/* { dg-final { scan-assembler-not "lea\[lq\]" } } */