[RFC][PATCH] New expf, exp2f, logf, log2f and powf implementations
Wed Sep 6 06:58:00 GMT 2017
On Sep 5 00:18, Wilco Dijkstra wrote:
> > 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.
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
- 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
#define __OBSOLETE_MATH __TGT_OBSOLETE_MATH
- Further checks in the code:
- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Newlib