From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8342 invoked by alias); 19 Jan 2004 21:25:27 -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 8297 invoked from network); 19 Jan 2004 21:25:25 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 19 Jan 2004 21:25:25 -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 i0JLP0lh026371; Mon, 19 Jan 2004 21:25:01 GMT 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); Mon, 19 Jan 2004 21:26:22 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i0JLOx220353; Mon, 19 Jan 2004 21:24:59 GMT From: Joern Rennecke Message-Id: <200401192124.i0JLOx220353@linsvr1.uk.superh.com> Subject: Re: Floating point registers vs. LOAD_EXTEND_OP on alpha To: roger@eyesopen.com (Roger Sayle) Date: Mon, 19 Jan 2004 21:25:00 -0000 Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, joern.rennecke@superh.com (Joern Rennecke), rth@redhat.com (Richard Henderson) In-Reply-To: from "Roger Sayle" at Jan 18, 2004 10:18:59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2004 21:26:22.0951 (UTC) FILETIME=[E3012F70:01C3DED2] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-01/txt/msg01386.txt.bz2 > Hopefully, this analysis is enough for an alpha maintainer to determine > whether Joern needs an additional check in his post-reload patch or if > the alpha backend's LOAD_EXTEND_OP should claim to be extending in these > modes. P.S.: A more useful change of LOAD_EXTEND_OP would say that the extension only widens as far as it can without increasing the number of hard registers. Or that it just doesn't apply to registers that are smaller than word_mode. That would allow the SHmedia port to use LOAD_EXTEND_OP for SImode. That leaves the question how to best implement this in the register allocator. Maybe we are just trying to hard to keep a nice hack working without changing the way the RTL looks during combine. It would seem that things would be much saner if we required that an extend pattern much exist to match LOAD_EXTEND_OP for it to be effective, and when combine makes use if it, it replaces the load with a SIGN_EXTEND / ZERO_EXTEND as appropriate. (The code in cse does appear to already replace some MEMs with a copy from a sign / zero extension, rather than the other way round.) The main problem with this approach seems to keep track of when an extension is actually used. The tangle of last_value and cached sign and 'non'zero bits makes me wonder if it might be easier to make a register width aware flow pass for arbitrary integer modes <= word_mode.