On Fri, 2 Mar 2018, Konstantin Belousov wrote:
On Fri, Mar 02, 2018 at 12:43:34PM -0500, Pedro Giffuni wrote:
...
I think use of _Nonnull attributes in the threading functions may also
be a waste (I introduced them mostly to be compatible with Android).
FWIW, Dragonfly sprinkled some restrict there recently:
http://gitweb.dragonflybsd.org/dragonfly.git/commit/d33005aaee6af52c80428b59b52aee522c002492
Just in case someone is considering more cleanups.
This is not a cleanup for me, but a needed change. Right now x86
copyouts are implemented in asm, so whatever damage is done to the
prototypes, only effect is at the caller side. In my work, i386 copyouts
are done in C, so it starts matter.
That seems slow, especially for small sizes as are common for syscall args
(in 1 of my versions, copyin() of args is optimized to fuword() in a loop,
and fuword() is optimized to not use pcb_onfault, so it is not much more
than 1 memory access. However, in your i386 version this optimization
would be negative since the slow part is switching the map, so fuword()
should never be used to access multiple words). However, copyinstr() and
copystr() should never have been "optimized" by writing them in asm. On
x86, their asm is badly written so they are slower than simple C versions
except on 8088's and maybe 8086's and maybe on the original i386. (8088's
were limited mainly by instruction bandwidth and the original i386 wasn't
much better, so short CISC instructions like lodsb and stosb tended to be
faster than larger separate instructions despite their large setup overheads.
Also I looked at the dragonfly commit because I become curious what do you
mean by threading functions. The first example was
int pthread_attr_getguardsize(const pthread_attr_t * __restrict,
- size_t *);
+ size_t * __restrict);
POSIX agrees with the dragonfly change, but I do not understand it.
Aliasing rules already disallow the first and second arguments to point
to the same memory, because they have different types.
(1) thread_attr_t is opaque, so the types might be the same.
(2) pthread_attr_t might be a pointer to a struct/union containing a size_t.
(3) perhaps other reasons. I'm not sure how 'restrict interacts with global
variables or even it it prevents the interaction in (2). A previous
discussion showed that const doesn't make types different enough to
prevent aliasing. Similarly for volatile.
Similarly for other pointers to {opaque, struct/union, or even integer} types.
size_t can't be aliased to int, but it can be aliased to any unsigned type
in C and to any unsigned type not smaller than uint16_t in POSIX (POSIX
but not C requires u_char == uint8_t, so size_t can't be u_char in POSIX
but it can be u_char in C).
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
