From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11497 invoked by alias); 30 Jul 2013 20:22:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11470 invoked by uid 89); 30 Jul 2013 20:22:01 -0000 X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 30 Jul 2013 20:22:01 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6UKLr26011924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Jul 2013 16:21:53 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-21.phx2.redhat.com [10.3.113.21]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6UKLrng023484; Tue, 30 Jul 2013 16:21:53 -0400 Message-ID: <51F82060.8070701@redhat.com> Date: Tue, 30 Jul 2013 20:23:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: DJ Delorie CC: gcc-patches@gcc.gnu.org Subject: Re: msp430 port References: <51E700D1.702@redhat.com> <201307232208.r6NM8QpY018297@greed.delorie.com> <51F804CA.1050109@redhat.com> <201307301847.r6UIlY32014729@greed.delorie.com> In-Reply-To: <201307301847.r6UIlY32014729@greed.delorie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg01509.txt.bz2 On 07/30/2013 12:47 PM, DJ Delorie wrote: > >>> +; Note: using POPM.A #1 is two bytes smaller than using POPX.A.... >>> + >>> +(define_insn "movsipsi2" >>> + [(set (match_operand:PSI 0 "register_operand" "=r") >>> + (subreg:PSI (match_operand:SI 1 "register_operand" "r") 0))] >>> + "TARGET_LARGE" >>> + "PUSH.W %H1 { PUSH.W %1 { POPM.A #1, %0" >>> +) >> So how is this different fram >> (set (psi) (truncate:psi (si)))? > > It should be the same, of course. I typically look at what gcc *is* > generating, not what it *should* be generating, though ;-) > > GCC does a lot of silly things these days. Well, you need to show why GCC is generating this and we need to evaluate whether or not it's safe. I'm very leery of anything using a PSImode SUBREG on a port where truncation is not a nop. > >>> +; This pattern is needed in order to avoid reload problems. >>> +; It takes an SI pair of registers, adds a value to them, and >>> +; then converts them into a single PSI register. >>> + >>> +(define_insn "addsipsi3" >>> + [(set (subreg:SI (match_operand:PSI 0 "register_operand" "=&r") 0) >>> + (plus:SI (match_operand:SI 1 "register_operand" "0") >>> + (match_operand 2 "general_operand" "rmi"))) >>> + (clobber (reg:CC CARRY)) >>> + ] >>> + "" >>> + "ADD.W\t%L2, %L0 { ADDC.W\t%H2, %H0 { PUSH.W %H0 { PUSH.W %L0 { POPM.A #1, %0" >>> + >> Is it possible the insns which resulted in adding this pattern came from >> trying to zero/sign extend the frame pointer, then the frame pointer >> gets eliminated and turns into a (plus (sp) (const_int)? > > It's possible that's one case, but *all* pointer math happens in > SImode since the pointer_plus change went in. So this pattern happens > a lot. I'm very aware that all pointer math happens in SImode. My point is you need to find out *why* pattern was needed, explain it to this list so that we can evaluate if it's the right solution. I brought up the issue from the mn102 port because there's some reasonable chance it's the same problem. If it is the same problem, then we can discuss which is the better solution or if we hate them both, look at what it might take to fix reload. jeff