Re: PATCH to rs6000.md, comments?

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 07:09 16.07.98 , David S. Miller wrote:
>   Date: Wed, 15 Jul 1998 18:02:55 -0600
>   From: Jeffrey A Law <law@cygnus.com>
>
>     In message <98071601501700.28356@ns1102.munich.netsurf.de>you write:
>     > >I would recommend against folks spending time on this right now, our
>     > >concentration should be on stabilizing for egcs-1.1, not adding new
>     > >optimizations.
>     > 
>     > Uah, I don't agree!! First I don't think the CONSTANT_P_RTX is
>     > an optimization,
>
>   The new code is deferring the evaluation to a later point in the compiler;
>   the warning occurs because the backend does not support deferred
evaluation.
>
>   The deferred evaluation is an optimization.  Thus it is not critical
>   for egcs-1.1.  If it was necessary for correct behavior I would have
>   objected to it going in without someone fixing all the backends at
>   the same time.
>
>It is an optimization, but here it is a special case since it was
>added specifically so that the next release of glibc could rewrite all
>their ugly string.h optimized inline macros as inline functions
>instead to solve many type casting problems.
>
>Therefore in my estimation it should at least be done for all backends
>which have a Linux subtarget, Uli would need to disable usage of this
>optimized string.h header file in glibc (or worse, keep around two
>versions, the old and the new, and actually this is not an option
>because the old one not working is why these egcs features were added
>in the first place!) on egcs targets where the work was not done.  He
>would need to do this because none of the inline function versions of
>the string.h optimizations of glibc would ever work (they are
>dependant upon builtin_constant_p() working for args passed to inline
>functions).

Ah, now this is the explanation I was asking for earlier, thanks. If this
is a glibc thing I consider this as _extremely_ important for egcs-1.1 on
powerpc-linux.

>And to top this off, the work to do it is _insanely trivial_, find
>every target specific predicate which accepts CONST_INT and make it
>accept CONSTANT_P_RTX in the same spots, update PREDICATE_CODES as
>necessary.  That's it, nothing more.  It's mindless and cannot
>introduce bugs because only people who use the new builtin constant
>feature can hit the code where the changes are made.  And whats more,
>CONSTANT_P_RTX is only around during insn matching, the predicate need
>only accept it, no other part of the port needs to even deal with it
>because final RTL will never constain a CONSTANT_P_RTX.

And another thing I was asking for, an explanation of what to do about
that. From looking at other patches it looked simple, but nobody presented
a rule yet. I will work out a patch and post it here.

David, one question, there are 2 or 3 constructs like the ones below in
rs6000.c, should I return 1 for CONSTANT_P_RTX in both cases?

Franz.


/* Return 1 if the operand is a non-special register or a constant that
   can be used as the operand of an OR or XOR insn on the RS/6000.  */

int
logical_operand (op, mode)
     register rtx op;
     enum machine_mode mode;
{
  return (gpc_reg_operand (op, mode)
          || (GET_CODE (op) == CONST_INT
              && ((INTVAL (op) & (~ (HOST_WIDE_INT) 0xffff)) == 0
                  || (INTVAL (op) & 0xffff) == 0)));
}

/* Return 1 if C is a constant that is not a logical operand (as
   above).  */

int
non_logical_cint_operand (op, mode)
     register rtx op;
     enum machine_mode mode ATTRIBUTE_UNUSED;
{
  return (GET_CODE (op) == CONST_INT
          && (INTVAL (op) & (~ (HOST_WIDE_INT) 0xffff)) != 0
          && (INTVAL (op) & 0xffff) != 0);
}