summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Increase and decrease in_sigcancel_handler accordingly to avoid possibledavidxu2008-03-051-2/+2
| | | | error caused by nested SIGCANCEL stack, it is a bit complex.
* Use cpuset defined in pthread_attr for newly created thread, for now,davidxu2008-03-053-21/+57
| | | | | | | we set scheduling parameters and cpu binding fully in userland, and because default scheduling policy is SCHED_RR (time-sharing), we set default sched_inherit to PTHREAD_SCHED_INHERIT, this saves a system call.
* Add more cpu affinity function's symbols.davidxu2008-03-051-0/+6
|
* Check actual size of cpuset kernel is using and define underscore versiondavidxu2008-03-051-7/+42
| | | | of API.
* If a new thread is created, it inherits current thread's signal masks,davidxu2008-03-043-1/+24
| | | | | | | | however if current thread is executing cancellation handler, signal SIGCANCEL may have already been blocked, this is unexpected, unblock the signal in new thread if this happens. MFC after: 1 week
* Include cpuset.h, unbreak compiling.davidxu2008-03-041-0/+2
|
* implement pthread_attr_getaffinity_np and pthread_attr_setaffinity_np.davidxu2008-03-044-3/+68
|
* Implement functions pthread_getaffinity_np and pthread_setaffinity_np todavidxu2008-03-033-1/+78
| | | | get and set thread's cpu affinity mask.
* - Fix an off-by-one bug in _libelf_insert_section(). [1]jkoshy2008-03-031-5/+11
| | | | | | - Update (c) years. Submitted by: kaiw [1]
* 1 << 47 needs to be written 1ULL << 47.das2008-03-021-1/+1
|
* Add cpuset, an api for thread to cpu binding and cpu resource groupingjeff2008-03-021-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | and assignment. - Add a reference to a struct cpuset in each thread that is inherited from the thread that created it. - Release the reference when the thread is destroyed. - Add prototypes for syscalls and macros for manipulating cpusets in sys/cpuset.h - Add syscalls to create, get, and set new numbered cpusets: cpuset(), cpuset_{get,set}id() - Add syscalls for getting and setting affinity masks for cpusets or individual threads: cpuid_{get,set}affinity() - Add types for the 'level' and 'which' parameters for the cpuset. This will permit expansion of the api to cover cpu masks for other objects identifiable with an id_t integer. For example, IRQs and Jails may be coming soon. - The root set 0 contains all valid cpus. All thread initially belong to cpuset 1. This permits migrating all threads off of certain cpus to reserve them for special applications. Sponsored by: Nokia Discussed with: arch, rwatson, brooks, davidxu, deischen Reviewed by: antoine
* Translate the r_info field of ELF relocation records when convertingjkoshy2008-03-022-4/+23
| | | | | | between 64 and 32 bit variants. Submitted by: kaiw
* Hook up sqrtl() to the build.das2008-03-025-13/+24
|
* MD implementations of sqrtl().das2008-03-022-0/+76
|
* MI implementation of sqrtl(). This is very slow and shoulddas2008-03-023-4/+168
| | | | be overridden when hardware sqrt is available.
* Use the easily-greppable copyright notice template fromphilip2008-02-297-119/+119
| | | | | | src/share/examples/mdoc/POSIX-copyright. Requested by: ru
* Fix and improve some magic numbers for the "medium size" case.bde2008-02-282-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | e_rem_pio2.c: This case goes up to about 2**20pi/2, but the comment about it said that it goes up to about 2**19pi/2. It went too far above 2**pi/2, giving a multiplier fn with 21 significant bits in some cases. This would be harmful except for a numerical accident. It happens that the terms of the approximation to pi/2, when rounded to 33 bits so that multiplications by 20-bit fn's are exact, happen to be rounded to 32 bits so multiplications by 21-bit fn's are exact too, so the bug only complicates the error analysis (we might lose a bit of accuracy but have bits to spare). e_rem_pio2f.c: The bogus comment in e_rem_pio2.c was copied and the code was changed to be bug-for-bug compatible with it, except the limit was made 90 ulps smaller than necessary. The approximation to pi/2 was not modified except for discarding some of it. The same rough error analysis that justifies the limit of 2**20pi/2 for double precision only justifies a limit of 2**18pi/2 for float precision. We depended on exhaustive testing to check the magic numbers for float precision. More exaustive testing shows that we can go up to 2**28pi/2 using a 53+25 bit approximation to pi/2 for float precision, with a the maximum error for cosf() and sinf() unchanged at 0.5009 ulps despite the maximum error in rem_pio2f being ~0.25 ulps. Implement this.
* Replace the use of warnx() with direct output to stderr using _write().scf2008-02-281-12/+36
| | | | | | | | | | | | | | | | This reduces the size of a statically-linked binary by approximately 100KB in a trivial "return (0)" test application. readelf -S was used to verify that the .text section was reduced and that using strlen() saved a few more bytes over using sizeof(). Since the section of code is only called when environ is corrupt (program bug), I went with fewer bytes over fewer cycles. I made minor edits to the submitted patch to make the output resemble warnx(). Submitted by: kib bz Approved by: wes (mentor) MFC after: 5 days
* Add <limits.h> for SHRT_MAX.jhb2008-02-273-0/+3
| | | | Pointy hat to: jhb
* File descriptors are an int, but our stdio FILE object uses a short to holdjhb2008-02-273-0/+39
| | | | | | | | | | | | | | | | | them. Thus, any fd whose value is greater than SHRT_MAX is handled incorrectly (the short value is sign-extended when converted to an int). An unpleasant side effect is that if fopen() opens a file and gets a backing fd that is greater than SHRT_MAX, fclose() will fail and the file descriptor will be leaked. Better handle this by fixing fopen(), fdopen(), and freopen() to fail attempts to use a fd greater than SHRT_MAX with EMFILE. At some point in the future we should look at expanding the file descriptor in FILE to an int, but that is a bit complicated due to ABI issues. MFC after: 1 week Discussed on: arch Reviewed by: wollman
* Spelling correction, thanks to Joerg Sonnenberger.kientzle2008-02-271-1/+1
|
* Optimize skipping over Zip entries.kientzle2008-02-271-14/+5
| | | | | Thanks to: Dan Nelson, who sent me the patch MFC after: 7 days
* stdio is currently limited to file descriptors not greater thanwollman2008-02-271-1/+19
| | | | | | | | {SHRT_MAX}, so {STREAM_MAX} should be no greater than that. (This does not exactly meet the letter of POSIX but comes reasonably close to it in spirit.) MFC after: 14 days
* Added the "restrict" type-qualifier to the readlink() prototype.ru2008-02-261-2/+2
|
* Rename the archive_endian.h functions to avoid name clasheskientzle2008-02-262-39/+41
| | | | | | with NetBSD's sys/endian.h file. Pointed out by: Joerg Sonnenberger
* Inline __ieee754__rem_pio2f(). On amd64 (A64) and i386 (A64), thisbde2008-02-254-0/+15
| | | | | | | | | | | | | gives an average speedup of about 12 cycles or 17% for 9pi/4 < |x| <= 2**19pi/2 and a smaller speedup for larger x, and a small speeddown for |x| <= 9pi/4 (only 1-2 cycles average, but that is 4%). Inlining this is less likely to bust caches than inlining the float version since it is much smaller (about 220 bytes text and rodata) and has many fewer branches. However, the float version was already large due to its manual inlining of the branches and also the polynomial evaluations.
* Use a temporary array instead of the arg array y[] for callingbde2008-02-252-8/+8
| | | | | | | | | | | | | | __kernel_rem_pio2(). This simplifies analysis of aliasing and thus results in better code for the usual case where __kernel_rem_pio2() is not called. In particular, when __ieee854_rem_pio2[f]() is inlined, it normally results in y[] being returned in registers. I couldn't get this to work using the restrict qualifier. In float precision, this saves 2-3% in most cases on amd64 and i386 (A64) despite it not being inlined in float precision yet. In double precision, this has high variance, with an average gain of 2% for amd64 and 0.7% for i386 (but a much larger gain for usual cases) and some losses.
* Change __ieee754_rem_pio2f() to return double instead of float so thatbde2008-02-255-27/+24
| | | | | | | | | | | | | | | | | | | | | | this function and its callers cosf(), sinf() and tanf() don't waste time converting values from doubles to floats and back for |x| > 9pi/4. All these functions were optimized a few years ago to mostly use doubles internally and across the __kernel*() interfaces but not across the __ieee754_rem_pio2f() interface. This saves about 40 cycles in cosf(), sinf() and tanf() for |x| > 9pi/4 on amd64 (A64), and about 20 cycles on i386 (A64) (except for cosf() and sinf() in the upper range). 40 cycles is about 35% for |x| < 9pi/4 <= 2**19pi/2 and about 5% for |x| > 2**19pi/2. The saving is much larger on amd64 than on i386 since the conversions are not easy to optimize except on i386 where some of them are automatic and others are optimized invalidly. amd64 is still about 10% slower in cosf() and tanf() in the lower range due to conversion overhead. This also gives a tiny speedup for |x| <= 9pi/4 on amd64 (by simplifying the code). It also avoids compiler bugs and/or additional slowness in the conversions on (not yet supported) machines where double_t != double.
* Add missing words.brueffer2008-02-251-2/+2
| | | | MFC after: 3 days
* Fix some off-by-1 errors.bde2008-02-253-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e_rem_pio2.c: Float and double precision didn't work because init_jk[] was 1 too small. It needs to be 2 larger than you might expect, and 1 larger than it was for these precisions, since its test for recomputing needs a margin of 47 bits (almost 2 24-bit units). init_jk[] seems to be barely enough for extended and quad precisions. This hasn't been completely verified. Callers now get about 24 bits of extra precision for float, and about 19 for double, but only about 8 for extended and quad. 8 is not enough for callers that want to produce extra-precision results, but current callers have rounding errors of at least 0.8 ulps, so another 1/2**8 ulps of error from the reduction won't affect them much. Add a comment about some of the magic for init_jk[]. e_rem_pio2.c: Double precision worked in practice because of a compensating off-by-1 error here. Extended precision was asked for, and it executed exactly the same code as the unbroken double precision. e_rem_pio2f.c: Float precision worked in practice because of a compensating off-by-1 error here. Double precision was asked for, and was almost needed, since the cosf() and sinf() callers want to produce extra-precision results, at least internally so that their error is only 0.5009 ulps. However, the extra precision provided by unbroken float precision is enough, and the double-precision code has extra overheads, so the off-by-1 error cost about 5% in efficiency on amd64 and i386.
* Let PowerPC world optionally build with -msoft-float. For FPU-less PowerPCraj2008-02-247-0/+17
| | | | | | | | | variations (e500 currently), this provides a gcc-level FPU emulation and is an alternative approach to the recently introduced kernel-level emulation (FPU_EMU). Approved by: cognet (mentor) MFp4: e500
* Optimize the 9pi/2 < |x| <= 2**19pi/2 case some more by avoiding anbde2008-02-232-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | fabs(), a conditional branch, and sign adjustments of 3 variables for x < 0 when the branch is taken. In double precision, even when the branch is perfectly predicted, this saves about 10 cycles or 10% on amd64 (A64) and i386 (A64) for the negative half of the range, but makes little difference for the positive half of the range. In float precision, it also saves about 4 cycles for the positive half of the range on i386, and many more cycles in both halves on amd64 (28 in the negative half and 11 in the positive half for tanf), but the amd64 times for float precision are anomalously slow so the larger improvement is only a side effect. Previous commits arranged for the x < 0 case to be handled simply: - one part of the rounding method uses the magic number 0x1.8p52 instead of the usual 0x1.0p52. The latter is required for large |x|, but it doesn't work for negative x and we don't need it for large |x|. - another part of the rounding method no longer needs to add `half'. It would have needed to add -half for negative x. - removing the "quick check no cancellation" in the double precision case removed the need to take the absolute value of the quadrant number. Add my noncopyright in e_rem_pio2.c
* Avoid using FP-to-integer conversion for !(amd64 || i386) too. Use thebde2008-02-222-6/+4
| | | | | | | | | | | | | | | | | | | FP-to-FP method to round to an integer on all arches, and convert this to an int using FP-to-integer conversion iff irint() is not available. This is cleaner and works well on at least ia64, where it saves 20-30 cycles or about 10% on average for 9Pi/4 < |x| <= 32pi/2 (should be similar up to 2**19pi/2, but I only tested the smaller range). After the previous commit to e_rem_pio2.c removed the "quick check no cancellation" non-optimization, the result of the FP-to-integer conversion is not needed so early, so using irint() became a much smaller optimization than when it was committed. An earlier commit message said that cos, cosf, sin and sinf were equally fast on amd64 and i386 except for cos and sin on i386. Actually, cos and sin on amd64 are equally fast to cosf and sinf on i386 (~88 cycles), while cosf and sinf on amd64 are not quite equally slow to cos and sin on i386 (average 115 cycles with more variance).
* Remove the "quick check no cancellation" optimization forbde2008-02-221-12/+1
| | | | | | | | | | | | | | | | | | 9pi/2 < |x| < 32pi/2 since it is only a small or negative optimation and it gets in the way of further optimizations. It did one more branch to avoid some integer operations and to use a different dependency on previous results. The branches are fairly predictable so they are usually not a problem, so whether this is a good optimization depends mainly on the timing for the previous results, which is very machine-dependent. On amd64 (A64), this "optimization" is a pessimization of about 1 cycle or 1%; on ia64, it is an optimization of about 2 cycles or 1%; on i386 (A64), it is an optimization of about 5 cycles or 4%; on i386 (Celeron P2) it is an optimization of about 4 cycles or 3% for cos but a pessimization of about 5 cycles for sin and 1 cycle for tan. I think the new i386 (A64) slowness is due to an pipeline stall due to an avoidable load-store mismatch (so the old timing was better), and the i386 (Celeron) variance is due to its branch predictor not being too good.
* Optimize the 9pi/2 < |x| <= 2**19pi/2 case on amd64 and i386 by avoidingbde2008-02-222-0/+18
| | | | | | | | | | | | | | | | | | | | | | the the double to int conversion operation which is very slow on these arches. Assume that the current rounding mode is the default of round-to-nearest and use rounding operations in this mode instead of faking this mode using the round-towards-zero mode for conversion to int. Round the double to an integer as a double first and as an int second since the double result is needed much earler. Double rounding isn't a problem since we only need a rough approximation. We didn't support other current rounding modes and produce much larger errors than before if called in a non-default mode. This saves an average about 10 cycles on amd64 (A64) and about 25 on i386 (A64) for x in the above range. In some cases the saving is over 25%. Most cases with |x| < 1000pi now take about 88 cycles for cos and sin (with certain CFLAGS, etc.), except on i386 where cos and sin (but not cosf and sinf) are much slower at 111 and 121 cycles respectivly due to the compiler only optimizing well for float precision. A64 hardware cos and sin are slower at 105 cycles on i386 and 110 cycles on amd64.
* Add an irint() function in inline asm for amd64 and i386. irint() isbde2008-02-221-0/+30
| | | | | | | | | | | | | the same as lrint() except it returns int instead of long. Though the extern lrint() is fairly fast on these arches, it still takes about 12 cycles longer than the inline version, and 12 cycles is a lot in applications where [li]rint() is used to avoid slow conversions that are only a couple of times slower. This is only for internal use. The libm versions of *rint*() should also be inline, but that would take would take more header engineering. Implementing irint() instead of lrint() also avoids a conflict with the extern declaration of the latter.
* Optimize the conversion to bits a little (by about 11 cycles or 16%bde2008-02-221-5/+13
| | | | | | | | | | | | on i386 (A64), 5 cycles on amd64 (A64), and 3 cycles on ia64). gcc tends to generate very bad code for accessing floating point values as bits except when the integer accesses have the same width as the floating point values, and direct accesses to bit-fields (as is common only for long double precision) always gives such accesses. Use the expsign access method, which is good for 80-bit long doubles and hopefully no worse for 128-bit long doubles. Now the generated code is less bad. There is still unnecessary copying of the arg on amd64 and i386 and mysterious extra slowness on amd64.
* Optimize the fixup for +-0 by using better classification for this casebde2008-02-221-2/+4
| | | | | and by using a table lookup to avoid a branch when this case occurs. On i386, this saves 1-4 cycles out of about 64 for non-large args.
* Fix rintl() on signaling NaNs and unsupported formats.bde2008-02-221-5/+3
|
* s/rcsid/__FBSDID/das2008-02-2279-241/+158
|
* Remove an unused variable.das2008-02-223-3/+3
|
* Eliminate some warnings.das2008-02-223-9/+3
|
* Note, as required by our agreement with IEEE/The Open Group, that the messagephilip2008-02-217-0/+140
| | | | | | | | queue manual pages excerpt the POSIX standard. Spotted by: Mindaugas Rasiukevicius <rmind -at- NetBSD.org> Reviewed by: imp MFC after: 1 day
* Sanity-check the block size.kientzle2008-02-211-0/+19
| | | | | Thanks to: Joerg Sonnenberger MFC after: 7 days
* Merge cosmetic changes from e_rem_pio2.c 1.10 (convert to __FBSDID();bde2008-02-191-6/+4
| | | | | | fix indentation and return type of __ieee754_rem_pio2()). Remove unused variables.
* Optimize for 3pi/4 <= |x| <= 9pi/4 in much the same way as forbde2008-02-191-18/+56
| | | | | | | | | | | | | | | | | | | | pi/4 <= |x| <= 3pi/4. Use the same branch ladder as for float precision. Remove the optimization for |x| near pi/2 and don't do it near the multiples of pi/2 in the newly optimized range, since it requires fairly large code to handle only relativley few cases. Ifdef out optimization for |x| <= pi/4 since this case can't occur because it is done in callers. On amd64 (A64), for cos() and sin() with uniformly distributed args, no cache misses, some parallelism in the caller, and good but not great CC and CFLAGS, etc., this saves about 40 cycles or 38% in the newly optimized range, or about 27% on average across the range |x| <= 2pi (~65 cycles for most args, while the A64 hardware fcos and fsin take ~75 cycles for half the args and 125 cycles for the other half). The speedup for tan() is much smaller, especially relatively. The speedup on i386 (A64) is slightly smaller, especially relatively. i386 is still much slower than amd64 here (unlike in the float case where it is slightly faster).
* Rearrange the polynomial evaluation for better parallelism. Thisbde2008-02-192-9/+9
| | | | | | | | | | saves an average of about 8 cycles or 5% on A64 (amd64 and i386 -- more in cycles but about the same percentage on i386, and more with old versions of gcc) with good CFLAGS and some parallelism in the caller. As usual, it takes a couple more multiplications so it will be slower on old machines. Convert to __FBSDID().
* Include O_BINARY in open() calls on platforms that support it.kientzle2008-02-192-3/+13
|
* Another tiny, tiny step towards Windows support. No, I don't plan tokientzle2008-02-191-1/+4
| | | | | ever commit the Windows support files to FreeBSD CVS. That would just be wrong.
* Someday I might forgive the standards bodies for omitting timegm().kientzle2008-02-191-5/+9
| | | | | | | | | | | Maybe. In the meantime, my workarounds for trying to coax UTC without timegm() are getting uglier and uglier. Apparently, some systems don't support setenv()/unsetenv(), so you can't set the TZ env var and hope thereby to coax mktime() into generating UTC. Without that, I don't see a really good alternative to just giving up and converting to localtime with mktime(). (I suppose I should research the Perl library approach for computing an inverse function to gmtime(); that might actually be simpler than this growing list of hacks.)
OpenPOWER on IntegriCloud