Re: [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

[Maarten Lankhorst <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Hey,

On 25-02-15 18:05, Ilia Mirkin wrote:
> On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett
> <baggett.patrick@gmail.com> 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
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau