This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 4/11/07, gellerich@de.ibm.com <gellerich@de.ibm.com> wrote:

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.

Perhaps I was too terse on my proposal. My thinking was, that from expand_builtin() function, we should call expand_builtin_interclass_mathfn() also for BUILT_IN_SIGNBIT case. e_b_i_m() function will check, if there is an appropriate optab present (please note the check for icode). In case this optab is not present we call expand_builtin_signbit(), just before expand_call. Something like this:

expand_builtin_interclass_mathfn()
{
...
 switch (DECL_FUNCTION_CODE (fndecl))
   {
    ...
   CASE_FLT_FN (BUILT_IN_SIGNBIT):
     builtin_optab = signbit_optab; break;
    ...
   }

 if (icode != CODE_FOR_nothing)
   {
     ...
     return target;
   }

  switch (DECL_FUNCTION_CODE (fndecl))
   {
    ...
   CASE_FLT_FN (BUILT_IN_SIGNBIT):
     rtx target1 = expand_builtin_signbit (exp, target);
     if (target1)
       return target1;
    ...
   }

target = expand_call (exp, target, target == const0_rtx);

 return target;
}


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))


IMO, you can simply expand the sequence of


read_status
and_status_with_constant
cond_set_value

for each optab.  Optimizers should resolve IOR of masked values to
just one AND, like in following case:
--cut here--
void check(void)
{
 int a = foo();
 int x,y;

 x = a & 2;
 y = a & 8;

 if (x || y)
   bar();
}
--cut here--

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?

Unfortunatelly, fxam is not a simple bit check of status bits. It returns a value that describes what is in %st(0). So we also rely on the above optimization to CSE FXAM and various OR and AND sequences.

Exploiting such instruction would, of course, suggest that all the
respective builtin functions cases are handled together, plus some support in
earlier phases.

All the infrastructure is already in place, just the expanders and optabs are missing...

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]