search for: specul

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 spe...

Hi, Yeah, now I understand the problem here. Thanks. But I too have another doubt in "Bounds check bypass store" In this example in the Speculative load hardening : unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller = ...;unsigned long untrusted_size_from_caller = ...;if (untrusted_size_from_caller < sizeof(local_buffer)) { // Speculative execution enters here with a too-large size. memcpy(local_buffer, untrus...

Hi all, I would like to propose "Speculative compilation support in ORC v2 JIT API" for this year GSoC summer project. Project Description: Speculative compilation support. One of the selling points of the concurrent ORC APIs is that you can start compiling a function before you need it, in the hope that by the time that you do...

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 m...

Hi, Has something related to speculative tracing changed between s10 FCS and the more recent nevada builds ? I was trying the specopen.d script from the Dtrace guide on a nevada machine and it failed with : dtrace: failed to enable ''./spec.d'': DIF program content is invalid To try and narrow things down a bit I w...

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 th...

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...

...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...

...ed within 11 weeks (summer time) and make a way to trunk for real use by people. Also, LLVM ORC v2 resembles more like a function based approach. I think it would be easier to built a runtime profiler around it and make use of that profile data in compilelayer of ORC to recompile hot functions speculatively with more optimization. As far as I know, many JIT implementations uses profilers to decide hot code functions than information from their intermediate representation because of the dynamic nature of compiled/interpreting source language. This make me focus more runtime profilers than an...

...g/D75942 - https://reviews.llvm.org/D75944 I'd like to request comments, feedback, and discussion. Beyond that, we would also like guidance on whether to upstream this pass. Thanks, Zola Bridges >From the documentation: Overview of the mitigation As the name suggests, the "speculative execution side effect suppression" mitigation aims to prevent any effects of speculative execution from escaping into the microarchitectural domain where they could be observed, thereby closing off side channel information leaks. In the case of Load Value Injection, we assume that specul...

...l also not have any of the other issues. > 2) DSL Frontends (e.g. OpenCL, my specific domain) will be able to mark library functions they know are safe. 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 processors). For other functions, it's even worse because the cost may be dependent on the input. Consider as a trivial example the well-loved recursive...

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&g...

..."blackbox_safety" control dependence. In this case > we will probably have some optional metadata on loads and > stores to indicate that the control dependence is actually on > GC safety. > > As a starting point, LLVM will conservatively 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...

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 > processors). For other functions, it's even worse because the cost may be > dependent on the input. Consider as a trivial example the well-...

...r." It is intended to protect against many side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even though it was built in response to LVI. For folks protecting against LVI, this is an option for mitigation. This is also an option for folks who want to try to mitigate against speculative execution vulnerabilities as a whole and who don't have high performance needs. As mentioned in the documentation this is not necessarily foolproof, but it's as close as we can get to closing all side channels. Zola Bridges On Wed, Mar 18, 2020 at 2:03 PM Zola Bridges <zbrid at g...

...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 form...

...ssion 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. isSafeToSpeculativelyExecute() is a query that, basically, determines whether it is safe to move an instruction that is executed conditionally into an unconditional context. One common use-case is hoisting loop-invariant instructions out of loops, durin...

...multiple threads at the same time, the resulting loads return 'undef'. This is different from the C++ memory model, which provides undefined behavior. What is the rationale for returning an undef on racing reads? LLVM Atomics and Concurrency guide also states the following "Note that speculative loads are allowed; a load which is part of a race returns undef, but does not have undefined behavior" If the speculative loads returns an undef and the returned value is used, then it results in an undefined behavior. Am I correct? If so, what is the purpose of returning an undef with a...

...any >> side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even >> though it was built in response to LVI. >> >> For folks protecting against LVI, this is an option for mitigation. This >> is also an option for folks who want to try to mitigate against speculative >> execution vulnerabilities as a whole and who don't have high performance >> needs. As mentioned in the documentation this is not necessarily foolproof, >> but it's as close as we can get to closing all side channels. >> >> Zola Bridges >> >>...

...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 Fl...