From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10772 invoked by alias); 1 Sep 2004 18:33:04 -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 10758 invoked from network); 1 Sep 2004 18:33:02 -0000 Received: from unknown (HELO atlrel7.hp.com) (156.153.255.213) by sourceware.org with SMTP; 1 Sep 2004 18:33:02 -0000 Received: from smtp1.cup.hp.com (smtp1.cup.hp.com [15.75.208.53]) by atlrel7.hp.com (Postfix) with ESMTP id BFF3C7FC; Wed, 1 Sep 2004 14:33:01 -0400 (EDT) Received: from hpsje.cup.hp.com (hpsje.cup.hp.com [15.244.96.221]) by smtp1.cup.hp.com (Postfix) with ESMTP id 60340851; Wed, 1 Sep 2004 11:33:01 -0700 (PDT) Received: (from sje@localhost) by hpsje.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.7.3 TIS Messaging 5.0) id LAA16834; Wed, 1 Sep 2004 11:33:01 -0700 (PDT) Date: Wed, 01 Sep 2004 18:33:00 -0000 From: Steve Ellcey Message-Id: <200409011833.LAA16834@hpsje.cup.hp.com> To: joern.rennecke@superh.com Cc: gcc@gcc.gnu.org Subject: Re: RFC: Using mode and code macros in *.md files In-Reply-To: <200409011200.i81C0iu10932@chloe.uk.w2k.superh.com> X-SW-Source: 2004-09/txt/msg00064.txt.bz2 > > One thought I had was this: If there were an IF mode (infinite > > precision), and a single basic floating point add for that mode > > > > (set (match_operand:IF ...) > > (plus:IF (match_operand:IF ...) > > (match_operand:IF ...))) > > > > and then there would be no basic add instruction for any other floating > > point mode (SF, DF, or XF) then GCC will extend any of those to IFmode > > to do the add. I tested that and GCC did the float_extends. > > But that would make your instructions non-canonical, thus a number of > optimizers - in particular combine - will fail to match your patterns. > > Unless you propose to change the canonical form to use extension to IF > in every operation, which would pretty much mean rewriting most of the > rtl optimizers and all the target ports... I hadn't thought about that. I did experiment with this a little by removing the addsf and adddf instructions from my ia64.md file and forcing it to use addxf. I added one new optmization to combine, removing '(float_extend:XF (float_truncate:SF XF)' type constructs if flag_unsafe_math_optimizations is set. This is now generating IA64 combined instructions (like add-mult) the way I want, I'll have to experiment some more to see if it stops other optimizations. Hopefully, with optimizations moving up into trees and SSA the RTL optimizations won't come into play as much. Steve Ellcey sje@cup.hp.com