Re: [RFC][PATCH] New expf, exp2f, logf, log2f and powf implementations

[Corinna Vinschen <vinschen at redhat dot com>]

On Sep  5 00:18, Wilco Dijkstra wrote:
> Hi,
> 
> > Any comment on the difference in code and data size? Just curious
> > if we are considering it on all targets.
> 
> When statically linking with GLIBC, I noticed text size of binaries using
> Szabolc's patch was around 1200 bytes smaller on AArch64 when using
> expf, logf and powf. Newlib uses an almost identical fdlibm version so the
> savings should be similar. Compile it on your favourite target, YMMV.
> 
> > What capabilities does it require of the target architecture? You
> > mentioned VFP. Does it require vector operations. If something
> > is assumed, if the minimum capabilities are not met, how well
> > does this code perform?
> 
> Very little, if double precision operations have similar performance as
> single precision, you will get a huge speedup. The source is standard C99
> so it doesn't require any vector extensions. What is required is decent
> support for uint64_t, so it works best on 32/64-bit ISAs.
> 
> For 8/16-bit ISAs or CPUs without hardware floating point you generally
> have to use integer arithmetic using a fast 32x32->64 bit multiplier, but
> that requires a different algorithm. If your CPU doesn't have a multiplier(!?!)
> then CORDIC is your only option. However newlib isn't optimizing for these
> targets today, so this patch isn't aiming to either.
> 
> Mixed-endian IEEE formats could be supported but the various asuint()
> functions would need porting (same for issignaling). Non-IEEE formats would
> be harder given the use of integer masking to manipulate floating point values.
> 
> Wilco

Ok, I retract my reservations against OBSOLETE_MATH as such.  However,
there are a few problems with the current patch:

- Rename to __OBSOLETE_MATH (two underscores) so as not to spoil the
  namespace.

- The current implementation disallows a developer to override the
  setting from, e. g., sys/config.h or the command line.  As a minimum,
  __OBSOLETE_MATH should only be set if it isn't already set, and the
  checks for __OBSOLETE_MATH should check for being != 0:

  - #define __TGT_OBSOLETE_MATH 1 in arm and aarch cases

  - At the end of the file

    #ifndef __OBSOLETE_MATH
    #define __OBSOLETE_MATH __TGT_OBSOLETE_MATH
    #endif
  
  - Further checks in the code:

    #if __OBSOLETE_MATH

    rather than

    #ifdef __OBSOLETE_MATH

- The header of ieeefp.h explains the options.  Add __TGT_OBSOLETE_MATH /
  __OBSOLETE_MATH and add an informative comment along the lines of the
  above text, so developers have enough info to decide if they want to
  enable this for their target.

Not sure if __TGT_OBSOLETE_MATH is a good name, though.  I'm open for
better suggestions.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature