From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19708 invoked by alias); 17 Jun 2009 06:17:24 -0000 Received: (qmail 19694 invoked by uid 22791); 17 Jun 2009 06:17:23 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Jun 2009 06:17:17 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Wed, 17 Jun 2009 02:17:11 -0400 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 23:11:02 -0700 Received: from localhost ([64.169.86.201]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 23:11:02 -0700 From: Adam Nemet MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19000.35070.420049.574430@ropi.home> Date: Wed, 17 Jun 2009 06:17:00 -0000 To: Jeff Law Cc: Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: Rationale for an old TRUNCATE patch In-Reply-To: <4A385135.3070308@redhat.com> References: <4A385135.3070308@redhat.com> 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/msg00394.txt.bz2 Jeff Law writes: > Ian Lance Taylor wrote: > > 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. > > > Based on reviewing my old notes, we do have to ensure that combine > doesn't replace a TRUNCATE with a SUBREG as that can result in having a > 32bit value that isn't sign-extended, which clearly causes MIPS64 ports > grief. Thanks for the long information in your other reply. As I said in the original email, we are not turning a TRUNCATE into a SUBREG in this transformation. We're just simplifying the input expression to truncate with the knowledge that only the truncated mode bits are relevant from the input. At the end we are still left with a truncate expression but possibly with a simpler operand. Adam