From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10496 invoked by alias); 16 Jun 2009 14:35:50 -0000 Received: (qmail 10488 invoked by uid 22791); 16 Jun 2009 14:35:50 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Jun 2009 14:35:42 +0000 Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id n5GEZcbY005853 for ; Tue, 16 Jun 2009 07:35:40 -0700 Received: from pzk26 (pzk26.prod.google.com [10.243.19.154]) by spaceape23.eur.corp.google.com with ESMTP id n5GEZZ6d032047 for ; Tue, 16 Jun 2009 07:35:36 -0700 Received: by pzk26 with SMTP id 26so3122464pzk.6 for ; Tue, 16 Jun 2009 07:35:35 -0700 (PDT) Received: by 10.114.46.6 with SMTP id t6mr13968241wat.17.1245162935370; Tue, 16 Jun 2009 07:35:35 -0700 (PDT) Received: from localhost.localdomain.google.com ([67.218.105.128]) by mx.google.com with ESMTPS id v39sm752681wah.27.2009.06.16.07.35.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 07:35:34 -0700 (PDT) To: Adam Nemet Cc: gcc@gcc.gnu.org, law@redhat.com Subject: Re: Rationale for an old TRUNCATE patch References: From: Ian Lance Taylor Date: Tue, 16 Jun 2009 14:35:00 -0000 In-Reply-To: (Adam Nemet's message of "16 Jun 2009 00\:07\:20 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true 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-06/txt/msg00369.txt.bz2 Adam Nemet writes: > I am trying to understand the checkin by Jeff Law from about 11 years ago: > > r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines > > > * combine.c (simplify_rtx, case TRUNCATE): Respect value of > TRULY_NOOP_TRUNCATION. > > > Index: combine.c > =================================================================== > --- combine.c (revision 19018) > +++ combine.c (revision 19204) > @@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest > if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) > break; > > - if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) > + if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT > + && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), > + GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0))))) > SUBST (XEXP (x, 0), > force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), > GET_MODE_MASK (mode), NULL_RTX, 0)); > > This optimization simplifies the input to a truncate by only computing bits > that won't be eliminated by the truncation. Normally these are the bits in > the output mode mask. Note that the optimization does not change the truncate > into a low-part subreg, which would pretty automatically warrant the > TRULY_NOOP_TRUNCATION check. I agree that this patch looks wrong in todays compiler. There should be no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. > Specifically I am curious if this was prompted by MIPS (or SH) or maybe some > other target that have a notion of truncate different from MIPS. It pretty much has to have been MIPS or SH since I don't think any other target back then defined TRULY_NOOP_TRUNCATION as anything other than 1. Ian