From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19800 invoked by alias); 11 Apr 2007 12:58:45 -0000 Received: (qmail 19790 invoked by uid 22791); 11 Apr 2007 12:58:44 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.uk.ibm.com (HELO mtagate4.uk.ibm.com) (195.212.29.137) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Apr 2007 13:58:41 +0100 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l3BCwdDJ021122 for ; Wed, 11 Apr 2007 12:58:39 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3BCwcMQ2089078 for ; Wed, 11 Apr 2007 13:58:39 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3BCwcmQ018805 for ; Wed, 11 Apr 2007 13:58:38 +0100 Received: from dyn-9-152-216-65.boeblingen.de.ibm.com (dyn-9-152-216-65.boeblingen.de.ibm.com [9.152.216.65]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3BCwcJ4018793; Wed, 11 Apr 2007 13:58:38 +0100 Received: by dyn-9-152-216-65.boeblingen.de.ibm.com (Postfix, from userid 1000) id B8F8C110246; Wed, 11 Apr 2007 14:56:09 +0200 (CEST) Date: Wed, 11 Apr 2007 12:58:00 -0000 From: gellerich@de.ibm.com To: ubizjak@gmail.com, gcc-patches@gcc.gnu.org Cc: gelleric@tuxmaker.boeblingen.de.ibm.com Subject: Re: [PATCH] add insn implementing signbit to middle end and s390 Message-ID: <461CDAE9.mailI881XWOCW@de.ibm.com> References: <5787cf470704030718i4c62f1abs9fa03d1e787e9957@mail.gmail.com> In-Reply-To: <5787cf470704030718i4c62f1abs9fa03d1e787e9957@mail.gmail.com> User-Agent: nail 11.4 8/29/04 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-04/txt/msg00554.txt.bz2 %% Regadring your patch: It looks to me you are somehow reinventing %% expand_builtin_interclass_mathfn() functionality. The patch for isinf %% (please look at my ChangeLog entry from 2007-01-31) added %% infrastructure that handles builtins with FP mode arguments and SImode %% outputs using generic optab handling. %% Perhaps you could enhance expand_builtin_interclass_mathfn() to %% fallback to generic signbit handling (expand_builtin_signbit) in case %% named pattern is not available? %% BTW: You could implement isinf() just by adding appropriate named %% pattern to s390.md. Please look at "isinf2" expander in %% config/i386/i386.md Hello Uros, Many thanks for your detailed comments! Actually, I already defined isinf this way and currently do some testing. I agree that very similar things are usually best handled in the same function. One of the next enhancements I plan is an implementation for isnan and it will probably be a straight-forward extension of expand_builtin_interclass_mathfn(), similar to isinf. However, I am uncertain as far as putting parts of the implementation of expand_builtin_signbit() into expand_builtin_interclass_mathfn() given that expand_builtin() has already identified the signbit builtin as such. That test would have to be repeated. Since that the primary purpose of my patch is to introduce the signbit pattern I would prefer to keep it in expand_builtin_signbit() for now. This does, of course, not prevent a later reorganization. By the way, there is a chance for a new optimization. The s390 instruction I am going to exploit with this and some future patches is able to test the contents of a float register for all those IEEE special values like infinity, different kinds of NaN etc. A bit mask controls what the instruction actually looks for. This means, one instruction with an appropriate bit mask is sufficient to implement an expression like (isnan(x) || isinf(x)) I know of at least one other processor (gcc target spu) that has a similar instruction, and probably there are more. Isn't the i386 FXAM organized like this, too? Exploiting such instruction would, of course, suggest that all the respective builtin functions cases are handled together, plus some support in earlier phases. Best regards, Wolfgang --- Dr. Wolfgang Gellerich IBM Deutschland Entwicklung GmbH Schönaicher Strasse 220 71032 Böblingen, Germany Tel. +49 / 7031 / 162598 gellerich@de.ibm.com ======================= IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294