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]

Re: PATCH to rs6000.md, comments?


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

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.

Later,
David S. Miller
davem@dm.cobaltmicro.com


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