On 01/08/2018 09:01 AM, Bill Schmidt wrote:
> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
> <richard.earns...@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;
>> }
>> else
>> 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.
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.
jeff
