On 01/08/2018 07:19 AM, Bill Schmidt wrote: > >> 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. So my concern is that if we have multiple builtins to deal with this problem, then we're forcing the pain of figuring out which one to use onto the users.
I'd really like there to be a single builtin to address this problem. Otherwise the kernel (and anyone else that wants to use this stuff) is stuck with using both, conditional compilation or something along those lines which seems like a huge lose. We'd really like them to be able to add one appropriate __builtin_whatever call at the key site(s) that does the right thing regardless of the architecture. I think that implies we're likely to have arguments that are unused on some architectures. I can live with that. But it also implies we need better language around the semantics. As you mention -- there's some belief that we're going to want to do something for automatic detection in the. I think a builtin for that could well be different than what we provide to the kernel folks in the immediate term. I want to focus first on getting a builtin the kernel guys can use today as needed though. Jeff
