remove deprecated REG_LIBCALL / REG_RETVAL from (Was Re:

Joern Rennecke
Mon Aug 16 19:05:00 GMT 2004

> Test Run By stevenb on Fri Aug 13 18:30:49 2004
> Native configuration is x86_64-unknown-linux-gnu

I did some comparative gdb runs and dug a bit in the sources.
It turns out that for glibc2 based linux targets, TARGET_C99_FUNCTIONS is
set, and both folding of cabs* with constant arguments and constant
propagation into it is done at the tree level with -ffast-math.
(With -ffast-math, fold_builtin_cabs expands the complex absolute using
 sqrt / sqrtf / sqrtl, but only if the compiler thinks there are library
 functions available for them.  Which doesn't really make sense, since
 a fused library function implementation of hypot / hypotf / hypotl can
 be faster than software-floating point double multiply / add / sqrt* .
 This expansion is mainly beneficial if you have hardware operations for
 multiply / add / sqrt, but not for complex absolute, and should therefore
 test for the existence of the relevant expanders and possibly also some
 cost function. )

If you have a newlib-based target, however, constant propagation for
cabsf and cabsl doesn't work at the tree level.  If you have rtl patterns
for these operations that can be understood by cse.c, it will
do the constant propagation and the the folding for you on the rtl.  If you
only have an opaque call, you are out of luck.

> > No, I am saying that loop optimizations are not the only ones that
> > want to know the meaning of an operation, rather than its low-level coding.
> What are those other ones, and why?

Well, there is cse, as mentioned above, and there is combine, too.  Although
these really want the operation in the rtl itself, and a means to verify that
register lifetimes aren't unduly extended.

More information about the Gcc-patches mailing list