search for: speculative

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 for Select speculation cost. 3. Add a TargetTransformInfo callback for PhiNodeFoldingThreshold to enable speculation of more expe...

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

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

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

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

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 {

...ck. 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 branch) and *pointer2 & predicted_state - (else branch) right? Or out-of-processor's allow such access? Plus, why we are masking with all_zeros_mask during mis-prediction. Is there any reason for choosing all_zeros_mask? Cheers, Pra...

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

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

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

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

...%x = malloc() ;; known thread local > if (cond_0) { > store GCREF %val to %x > } > if (cond_1) { > store i64 %val to %x > } > > to > > %x = malloc() ;; known thread local > if (cond_0 || cond_1) { > store GCREF %val to %x ;; This "speculative" store is bad > if (cond_1) { > store i64 %val to %x > } > } > FWIW: This raises one of the same issues we have now with may-throw, which is that, if all you have is a flag on the instruction, now you have to look at every instruction in every block to know whe...

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

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

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

...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, during loo...

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

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

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,