This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()
Hi Richard and Jeff,
Sorry I missed this earlier today, it somehow ended up in my spam folder...
> On Jan 12, 2018, at 10:08 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> On 10/01/18 23:26, Jeff Law wrote:
>> On 01/08/2018 09:01 AM, Bill Schmidt wrote:
>>> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
>>>> On 08/01/18 02:20, Bill Schmidt wrote:
>>>>> Hi Richard,
>>>>> Unfortunately, I don't see any way that this will be useful for the ppc targets. We don't
>>>>> have a way to force resolution of a condition prior to continuing speculation, so this
>>>>> will just introduce another comparison that we would speculate past. For our mitigation
>>>>> we will have to introduce an instruction that halts all speculation at that point, and place
>>>>> it in front of all dangerous loads. I wish it were otherwise.
>>>> So can't you make the builtin expand to (in pseudo code):
>>>> if (bounds_check)
>>>> __asm ("barrier");
>>>> result = *ptr;
>>>> result = failval;
>>> Could, but this just generates unnecessary code for Power. We would instead generate
>>> __asm ("barrier");
>>> result = *ptr;
>>> without any checks. We would ignore everything but the first argument.
>> So how bad would it be to drop the whole concept of failval and make the
>> result indeterminate in the out of bounds case.
> Indeterminate on its own is too loose. An arbitrary value fetched from
> memory is 'indeterminate', so we'd need tighter wording that that, see
>> Would that give us enough freedom to generate an appropriate sequence
>> for aarch64 and ppc? It feels like these two architectures are
>> essentially on opposite sides of the spectrum and if we can find a
>> reasonable way to handle them that we'd likely have semantics we can use
>> on just about any architecture.
> So if we changed the specification (using the same parameter names) to:
> 1) When the call to the builtin is not being speculatively executed the
> result is *ptr if lower_bound <= cmpptr < upper_bound and undefined
> 2) When code is being speculatively executed either:
> a) execution of subsequent instructions that depend on the result
> will be prevented until it can be proven that the call to the
> builtin is not being speculatively executed (ie until execution
> can continue under point 1), or
> b) speculation may continue using *ptr as the result when
> lower_bound <= cmpptr < upper_bound, or an unspecified constant
> value (eg 0) if cmpptr lies outside that range.
> Then I think that meets those requirements.
This is quite acceptable for Power. Thanks, Richard, for your flexibility!
> We could still implement the existing relaxations on permitting the
> builtin to be called with only one of upper and lower.
> My concern is that this would make it quite hard for programmers to
> reason safely about the behaviour overall.