On Jan 8, 2018, at 1:40 PM, Jeff Law <l...@redhat.com> wrote: > > 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.
Hi Jeff, I agree 100% with this approach. I just wanted to raise the point in case other architectures have different needs. Power can work around this by just ignoring 4 of the 5 arguments. As long as nobody else needs *additional* arguments, this should work out just fine. But I want to be clear that the only guarantee of the semantics for everybody is that "speculation stops here," while on some processors it may be "speculation stops here if out of range." If we can write this into the documentation, then I'm fine writing a target expander for Power as discussed. I had a brief interchange with Richi last week, and he suggested that for the automatic detection we might look into flagging MEM_REFs rather than inserting a built-in; a target hook can still handle such a flag. That has some advantages and some disadvantages that I can think of, so we'll have to talk that out on the list over time after we get through the crisis mode reactions. Thanks! Bill > > Jeff
