[Intel-gfx] [PATCH] Antigcc bitfield bikeshed

[Jesse Barnes]

On 06/25/2015 12:33 AM, Daniel Vetter wrote:
>> In the specific case of bitfields it seems like it would be sufficient
>> > to mark the local variables as volatile?  Or maybe just use open coded
>> > compiler barrier() functions instead, with accompanying documentation.
>> > 
>> > Documentation/memory-barriers.txt is growing more and more interesting
>> > over the years (definitely more complicated than when I last added to it!).
> Yeah I'm honestly not too concerned about gcc making a mess in the two
> cases Chris want's to check something locklessly. It's more for
> documentation really so that when you read the code that special lockless
> access sticks out. Compiler barrier with a local variable might work, but
> the nice thing with ACCESS_ONCE&friends is that they also document exactly
> what the thing is you read locklessly.
> 
> Wrt comments: I thought the rule for comments on barriers is to make sure
> you don't forget to explain where the other side of the barrier is. Which
> very often is totally non-obvious. With lockless access we should have
> comments in headers already which locks protect which data (big emphasis
> on "should"), and the macros make it clear that lockless tricks are being
> played. So not sure what to add in comments. What do you have in mind?

Well I think they should document what ordering issue they're trying to
resolve.  What other code path depends on the specific ordering that the
ACCESS_ONCE provides in both of these cases?

> Aside: The two users in drm&i915 could all be replaced with READ_ONCE I
> think.

That would make things a little clearer, but we should still document
whether we're trying to make things work vs an interrupt handler, or
describe the reordering/folding/optimization we're trying to prevent
with the macro that would affect behavior.

Jesse