Displaying 3 results from an estimated 3 matches for "some_magic_th".
2015 Feb 25
2
[PATCH 2/2] nouveau: Do not add most bo's to the global bo list.
On Wed, Feb 25, 2015 at 10:35 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> pthread_mutex_lock had *better* imply a compiler barrier across which
> code can't be moved... which is very different from the printf case
> where it might have done it due to register pressure or who knows
> what.
>
In the dummy function, register pressure was certainly not an issue, but
2015 Feb 25
0
[PATCH 2/2] nouveau: Do not add most bo's to the global bo list.
...gt; 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.
-ilia
2015 Feb 25
2
[PATCH 2/2] nouveau: Do not add most bo's to the global bo list.
...es 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:/...