search for: speculation

Hi, The ComputeSpeculationCost() function in Transforms/Utils/SimplifyCFG.cpp uses a higher speculation cost for Select than other instructions. Does anyone know why this is? I would like SimplifyCFG to be able to speculatively execute Select instructions. Which of these solutions makes the most sense: 1. Change speculat...

...pointers with all_zeros_mask if >> there is a mis-prediction. But I understand that as soon as the condition >> value is available, the processor can check about it's assumptions and >> revert back. >> >> That is, >> If the branch prediction is correct during speculation, we mask with >> all_ones, the processor can follow the predicted branch to retire. >> But if the processor mispredicted the branch, it will revert back as soon >> as condition become available if this is the case then we don't execute >> speculatively the operations : p...

...C JIT implementations as LLJIT, LLLazyJIT. 2. [WIP]  Jit-linker a drop-in-replacement for RuntimeDyld atleast for MachO in ORC JIT. 3. Primitive code to handle speculative is in trunk. But it needs to refactored & designed to get generalized, simple APIs to support speculation. 4. Currently, no heuristics to support speculation in trunk. Proposed Solution: 1. New APIs in ORC v2 to support speculation compilation of LLVM bitcode. LLSpecJIT - subtype of LLJIT, default JIT with speculation support in trunk. 2. Heuristics to guide speculation -...

Hi, A new speculative cache side-channel vulnerability has been published at https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation, named "straight-line speculation”, CVE-2020-13844. In this email, I'd like to explain the toolchain mitigation we've prepared to mitigate against this vulnerability for AArch64. For the full details of the vulnerability, please follow the above link. The part of the vulnerability th...

...wrote the following short script. This works fine on s10, but fails with the above error on nevada builds 14, 17 and 19 (the only builds I have access to). I set dtrace_err_verbose=1 but didn''t get any more information. #!/usr/sbin/dtrace -s syscall::open:entry { self->spec = speculation(); speculate(self->spec); printf("%s", stringof(copyinstr(arg0))); } syscall::open:return /self->spec && errno != 0/ { commit(self->spec); self->spec = 0; } syscall::open:return /self->spec && errno == 0/ { discard(s...

Intel would like to contribute a patch to implement support for these Intel- and Microsoft -fp options. This message is to describe the options and request feedback from the community. -fp-model=[precise|strict|fast|except[-]] and -fp-speculation=[fast|strict|safe] This contribution would dovetail with the llvm patch "Teach the IRBuilder about constrained fadd and friends" which is under review here, https://reviews.llvm.org/D53157/new/. I have a patch ready to review that works with D53157. The motivation for providing these i...

While using DTrace to track down a problem recently, we came across an unexpected restriction: the compiler will not permit different speculations to be committed in the same instance of a probe identifier. For instance, consider the following useless D script: #!/usr/sbin/dtrace -s #pragma D option nspec=2 BEGIN { spec1 = speculation(); spec2 = speculation(); } END { commit(spec1); commit(spec...

...until the predicated state is computed, then we mask pointers with all_zeros_mask if there is a mis-prediction. But I understand that as soon as the condition value is available, the processor can check about it's assumptions and revert back. That is, If the branch prediction is correct during speculation, we mask with all_ones, the processor can follow the predicted branch to retire. But if the processor mispredicted the branch, it will revert back as soon as condition become available if this is the case then we don't execute speculatively the operations : pointer1 &= predicate_state - (if...

.... >> [WIP]  Jit-linker a drop-in-replacement for RuntimeDyld atleast >> for MachO in ORC JIT. >> 3. >> Primitive code to handle speculative is in trunk. But it needs to >> refactored & designed to get generalized, simple APIs to support >> speculation. >> 4. >> Currently, no heuristics to support speculation in trunk. >> >> >> Proposed Solution: >> >> 1. >> New APIs in ORC v2 to support speculation compilation of LLVM >> bitcode. LLSpecJIT - subtype of LLJIT, default JIT with >...

...ory access instructions or control flow instructions like RET) may receive injected data due to address aliasing, and we ensure these injected values are not allowed to steer later speculative memory accesses to impact cache contents. The mitigation is implemented as a compiler pass that inserts a speculation barrier (LFENCE) just before: - Each memory read instruction - Each memory write instruction - The first branch instruction in a group of terminators at the end of a basic block This is something of a last-resort mitigation: it is expected to have extreme performance impl...

On 31 Jul 2013, at 10:50, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > This has two main uses: > 1) Intrinsics, including target-dependent intrinsics, can be marked with this attribute – hopefully a lot of intrinsics that do not have explicit side effects and do not rely on global state that is not currently modeled by “readnone” (e.g. rounding

Hi all, I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM. In the design document here : https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening. <https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening> Example: void leak(int data);void example(int* pointer1,

...ively not speculate such > loads and stores; and will leave open the potential to upstream > logic that will have a more precise sense of when these loads and > stores are safe to speculate. > I think you need to define what you mean by control dependence here. If you mean speculation, you should say speculation :) As you describe below, it is not enough to simply not speculate them. You also are saying you don't want to change the conditions on which they execute. That is very different from speculation. > 3. Introduce a general way to denote control dependence on loa...

On 31 July 2013 11:56, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > The slightly orthogonal question to safety is the cost of execution. For > most intrinsics that represent CPU instructions, executing them > speculatively is cheaper than a conditional jump, but this is not the case > for all (for example, some forms of divide instructions on in-order RISC >

...ructions like RET) may receive injected data due to address aliasing, >> and we ensure these injected values are not allowed to steer later >> speculative memory accesses to impact cache contents. >> >> The mitigation is implemented as a compiler pass that inserts a >> speculation barrier (LFENCE) just before: >> >> - >> >> Each memory read instruction >> - >> >> Each memory write instruction >> - >> >> The first branch instruction in a group of terminators at the end of >> a basic block &...

...problem, because > we'd have to put it between the add and the select, and it would be > just as problematic. > > The current definition of nsw is an attempt to avoid arbitrary > limitations and keep the system as flexible as possible. > > One could argue that aggressive speculation is a low-level optimization > better suited to CodeGen than the optimizer, as LLVM divides them, and > that perhaps the cost for providing this level of flexibility in the > optimizer is too high, but that's a different argument. The optimizations we're talking about are forms of...

Hello, Chris requested I start a fresh discussion on this, so, here goes. The previous iterations can be found here (and in follow-ups): http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130722/182590.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064047.html Cutting to the chase, the goal is to enhance llvm::isSafeToSpeculativelyExecute() to support call instructions.

Hi all, I have been trying to understand the use of undef in both sequential and concurrent programs. >From the LLVM Language Reference Manual, I see the following definition of undef. "Undef can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern". LLVM Language Reference manual also demonstrates how optimizers

...data due to address aliasing, >>>> and we ensure these injected values are not allowed to steer later >>>> speculative memory accesses to impact cache contents. >>>> >>>> The mitigation is implemented as a compiler pass that inserts a >>>> speculation barrier (LFENCE) just before: >>>> >>>> - >>>> >>>> Each memory read instruction >>>> - >>>> >>>> Each memory write instruction >>>> - >>>> >>>> The first branch...

...be found again later. But that might not be quite so harmful because they at least contain a Loop as a contextual cue that prevents some leaking. So, my real question is does anyone know what the contract with ScalarEvolution is? I see a few possibilities: 1. Callers are expected to not engage in speculation. ScalarEvolution itself must only create expressions it knows hold in all cases. This sounds too restrictive to me. 2. Speculation not allowed outside ScalarEvolution, but ScalarEvolution can speculate about a specific Loop. I think this entails making non-AddRec expressions immutable (with Flags i...