Re: [PATCH] add insn implementing signbit to middle end and s390

[gellerich at de dot ibm dot com]

%% 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 "isinf<mode>2" 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