search for: speculatively

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

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

...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 speculatively compile everything we're quickly going to overload our memory/CPU resources, which will be lousy for performance. What we really want to do is to take into account any information we have (from high level program representations, e.g. ASTs or CFGs, or from profiling data from previous execu...

...;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 that is relevant to the toolchain mitigations is as follows. Some processors may speculatively execute the instructions immediately following what should be a change in control flow, including RET (returns), BR (indirect jumps) and BLR (indirect function calls). If the speculative execution path contains a suitable code sequence, often described as a "Spectre Revelation Gadget", su...

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 {

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

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

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

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

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

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

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

...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 speculative load? Is it to ensure that the subsequent uses of the value of the speculatively introduced load is caught/detected by the optimization? Is it possible to separate the "undef" in a sequential setting and "undef" with speculative loads in a concurrent setting with separate undefs? Thanks, Santosh -- Santosh G Nagarakatte, PhD Student, Computer and Infor...

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,