From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1803 invoked by alias); 9 Sep 2009 17:59:51 -0000 Received: (qmail 1755 invoked by uid 22791); 9 Sep 2009 17:59:49 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Wed, 09 Sep 2009 17:59:44 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n89HxgXc016299; Wed, 9 Sep 2009 13:59:42 -0400 Received: from stone.twiddle.home (vpn-227-123.phx2.redhat.com [10.3.227.123]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n89HxftL013376; Wed, 9 Sep 2009 13:59:41 -0400 Message-ID: <4AA7ED0C.7000607@redhat.com> Date: Wed, 09 Sep 2009 17:59:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Alex Turjan CC: Michael Matz , gcc@gcc.gnu.org Subject: Re: question about DSE References: <589093.37887.qm@web62408.mail.re1.yahoo.com> In-Reply-To: <589093.37887.qm@web62408.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00184.txt.bz2 On 09/09/2009 09:59 AM, Alex Turjan wrote: > 1.What do you think about this implementation? using define_insn_and_split If this port uses BITS_PER_WORD=16, then the lower-subreg pass may be able to give you better register allocation by disconnecting the low and high parts of the 32-bit value. If this port uses BITS_PER_WORD=32, then lower-subreg can't do anything, and you may get better assembly by using the post-reload splitter. > 2.Is is true that in the define_expand constructs I should avoid inducing subregs? It's true that you should *always* avoid calling gen_rtx_SUBREG directly, and instead use one of gen_lowpart, gen_highpart, or simplify_gen_subreg. r~