Re: [PATCH v2 4/7] exec: Use const alias for TARGET_PAGE_BITS_VARY

[Richard Henderson <richard.henderson@linaro.org>]

On 10/25/19 5:01 PM, Peter Maydell wrote:
> On Fri, 25 Oct 2019 at 21:43, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> On 10/25/19 10:51 AM, Peter Maydell wrote:
>>>> + * We want to declare the "target_page" variable as const, which tells
>>>> + * the compiler that it can cache any value that it reads across calls.
>>>> + * This avoids multiple assertions and multiple reads within any one user.
>>>> + *
>>>> + * This works because we initialize the target_page data very early, in a
>>>> + * location far removed from the functions that require the final results.
>>>
>>> I have to say that this feels like a worryingly large amount
>>> of magic. Is this actually guaranteed to work by the compiler?
>>
>> Yes.
> 
> I'm curious to know how the compiler engineers define
> "very early" and "far removed" -- in my experience they
> usually prefer to be more precise than that :-)

I remembered putting more precise language in there, but I don't see it now.
Perhaps I just dreamt it.

The last write to the non-const variable happens before the first time we
access the const variable.  At the first access to the const variable, we
assert that it has been initialized.

There's no specific barrier to avoid that first read of the const variable not
be hoisted by the compiler before the last store of the non-const variable,
except for being in a separate function, in a separate compilation unit, and
thus "far away".

We could, perhaps, put a barrier() at the end of finalize_target_page_bits(),
documenting this fact against some future date when compilation with -flto is
viable.  I will say, though, that I've tried that recently and quite some work
is required before one could enable -flto.  In the meantime, the barrier()
would compile away to nothing.


r~