RFR: Common TLS access to GC state, where possible

[Aleksey Shipilev]

On 01/15/2018 03:07 PM, Roman Kennke wrote:
> Ok. This is not so separate though. What I was suggesting in this last comment was to also common
> the actual checks, so your above example could become (assuming same flags):
> 
>    mov %r11, 0x3d8(TLS)
>    and $0x2, %r11
>    test %r11, %r11
>    jne SLOW
>    ...
> 
> I am not (yet) suggesting to move any barriers around. All I care about for now is commoning the
> loads, and when that works, also commoning the tests. This alone should lead to nice groups of
> barriers under one flag-load-test, and a fast path without barriers. Or not?

If would, but it requires rewiring the control flow (that what I meant by "moving the barriers",
probably confusingly), while this particular change just commons the accesses to the flag itself. In
my mind, this is orthogonal to rewiring the control flow, and it caters for cases where rewiring is
not possible due to structural reasons.

In other words, you want three things:
 a) Detect the GC state load;
 b) Common the GC state loads over multiple branches;
 c) Try to rewire branches so that huge happy paths are present under single branch;

The patch in this RFR does (a) [provides scaffolding] and (b) [experimentally, disabled by default,
as proof-of-concept such commoning is possible and available for performance testing if needed]. (c)
would work even if (c) is not possible in a particular case. It seems odd to wait for (c) before
pushing (a)+(b) out, right?

Thanks,
-Aleksey