> On Jan 7, 2018, at 10:47 PM, Jeff Law <l...@redhat.com> wrote:
>
> On 01/07/2018 07:20 PM, 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 could you have an expander for __builtin_load_no_speculate that just
> emits the magic insn that halts all speculation and essentially ignores
> the additional stuff that __builtin_load_no_speculate might be able to
> do on other platforms?
This is possible, but the builtin documentation is completely misleading for
powerpc. We will not provide the semantics that this builtin claims to provide.
So at a minimum we would need the documentation to indicate that the additional
range-checking is target-specific behavior as well, not just the speculation
code.
At that point it isn't really a very target-neutral solution.
What about other targets? This builtin seems predicated on specific behavior
of ARM architecture; I don't know whether other targets have a guaranteed
speculation-rectifying conditional test.
For POWER, all we would need, or be able to exploit, is
void __builtin_speculation_barrier ()
or some such. If there are two dangerous loads in one block, a single call
to this suffices, but a generic solution involving range checks for specific
loads would require one per load.
Thanks,
Bill
>
> jeff
>
