Hey, On 25-02-15 18:05, Ilia Mirkin wrote: > On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett > <[email protected]> wrote: >>> If code like >>> >>> x = *a; >>> pthread_mutex_lock or unlock or __memory_barrier() >>> y = *a; >>> >>> doesn't cause a to get loaded twice, then the compiler's in serious >>> trouble. Basically functions like pthread_mutex_lock imply that all >>> memory is changed to the compiler, and thus need to be reloaded. >>> >> Well, I've said before and I might be alone, but I disagree with you. The >> compiler is under no requirement to reload (*a) because a lock was changed. >> It does, but it doesn't have to. It's fine if you guys don't want to change >> it. It may never be a problem with gcc. >> >> This is the definition of pthread_mutex_lock() in glibc. There aren't any >> magic hints that this invalidates memory: >> >> extern int pthread_mutex_lock (pthread_mutex_t *__mutex) >> __THROWNL __nonnull ((1)); >> >> THOWNL is attribute((nothrow)). > > Hm, this is actually a little worrying. Maarten, thoughts? I would > have assumed there'd be a __attribute__((some_magic_thing)) in there. In general things don't get optimized across function calls, except in case of inlinable functions.
And for compiler attributes it's the opposite,__attribute__((const)) and __attribute((pure)) can be used to indicate some kind of safety to optimize across functions. https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html ~Maarten _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
