From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22334 invoked by alias); 22 Apr 2004 14:28:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22312 invoked from network); 22 Apr 2004 14:28:13 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 22 Apr 2004 14:28:13 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i3MES5kB008270; Thu, 22 Apr 2004 15:28:12 +0100 (BST) Received: from linsvr1.uk.superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 15:29:53 +0100 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i3MES0q32605; Thu, 22 Apr 2004 15:28:00 +0100 From: Joern Rennecke Message-Id: <200404221428.i3MES0q32605@linsvr1.uk.superh.com> Subject: Re: Exploiting dual mode operation To: LEEHOD@il.ibm.com (Leehod Baruch) Date: Thu, 22 Apr 2004 14:59:00 -0000 Cc: joern.rennecke@superh.com (Joern Rennecke), gcc@gcc.gnu.org, NAMOLARU@il.ibm.com (Mircea Namolaru) In-Reply-To: from "Leehod Baruch" at Apr 22, 2004 04:33:45 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 14:29:53.0053 (UTC) FILETIME=[46B1DCD0:01C42876] X-Scanned-By: MIMEDefang 2.41 X-SW-Source: 2004-04/txt/msg01068.txt.bz2 > We see redundant sign extension removal as a partial > redundancy problem. This will give us not only the redundant > sign extensions, but also better placement for the > remaining ones. As a result sign extension instructions > may be moved and instructions that uses the highpart > may be replaced with others that doesn't use it. Why would you be using the highpart if you don't need to in the first place? Or are you saying that the port will have to duplicate patterns that manipulate the highpart, to have a variant that uses and sets only a smaller SUBREG, so that you can avoid tracking the lifeness of the highpart separately? That would be much more intrusive than adding an attribute. > This is not equivalent with live information for the highest > part of the registers. > > Our approach will not require changes in the description file > (which in our opinion is a major problem with your code) and will > limit the changes to much fewer files. Without a special attribute in the machine description, or new code that analyzes the md rtl to automatically generate this information, you will have only scant information to feed into PRE computations. And when you fix this problem, you will find that you need low-level rtl to feed this pass, and then you don't want to push up the register pressure with PRE.