search for: speculating

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 speculation cost of Select from 2 to 1. 2. Add a TargetTransformInfo callback

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

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 need it it is already compiled. However, if we just

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.

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 wrote the following short script. This works fine on s10, but

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

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 {

Hi, Thanks for your email, I understand that the execution stalls 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

Hi Bekket, Sorry for the delayed reply. By appropriate, I mean performance of compiled native code. I was referring other JIT implementations like LuaJIT & webkit FTL JIT to see how they implement their JIT. I have gone through the design of Spider Monkey & Android runtime (ART) JIT. As, you said both region based and method based compilation unit have their own advantage &

Hi everyone, Some Intel processors have a newly disclosed vulnerability named Load Value Injection. One pager on Load Value Injection: https://software.intel.com/security-software-guidance/software-guidance/load-value-injection Deep dive on Load Value Injection: https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection I wrote this compiler pass that can

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,

On Thu, Jul 14, 2016 at 4:48 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi all, > > It looks like the key controversial point is the bit about the extra > control dependence on loads and stores[0]. Generally the consensus is > that (please chime if you think otherwise) it is not reasonable to > make the safety (or semantics) of a load instruction depend

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 >

Hi everyone! I want to clarify the purpose and design of SESES. Thus far, I've characterized it as an LVI mitigation which is somewhat incorrect. SESES was built as a "big hammer." 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

On Dec 5, 2011, at 7:42 PM, Dan Gohman wrote: > For example, suppose we want to convert the && to &, and the ?: to a > select, in this code: > > if (a && (b ? (c + d) : e)) { > > because we have a CPU architecture with poor branch prediction, or > because we want more ILP, or because of some other reason. Here's what the > LLVM IR for that might

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

I'm also a bit unclear on that point. I think one input here has to be: what are some example, existing codebases we want to mitigate, and what should the user experience be to mitigate them? I don't think we can make good engineering tradeoffs without having concrete use cases to evaluate. Another point: it seems some mitigation options have already been added to the GNU toolchain

Hi, I'm working on a bug somewhere between SCEV and IndVarSimplify, which tacks an unwanted "nuw" onto an "add i32 %whatever, -1" (which actually almost certainly will overflow), leading ultimately to an infinite loop. A fuller description and test-case is at the end for anyone interested. The issue seems to be with ScalarEvolution's attempts to cache SCEV objects,