search for: overapproxim

Dear all, I want to implement a pass that provides some kind of data flow integrity similar to Write Integrity Testing (https://www.doc.ic.ac.uk/~cristic/papers/wit-sp-ieee-08.pdf). This approach statically determines for each memory write the (conservative, overapproximated) points-to set of locations that can be written by the instruction. Further, it instruments the memory write instruction to prevent a write to a location not in the points-to set. How can I get the points-to set, including locations from stack/heap/static variables? How do I approach this prob...

...o: > Suppose I have in my CFG (among others) two basic blocks A and B, with > an edge from A to B. I need to do the following: > > * get the set S of live values across that edge > I forgot to add that it doesn't have to be exactely the set of live values: it can also be an overapproximation, i.e. S might contain also values that are not live anymore -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110614/98b64823/attachment.html> -------------- next part -------------- A non-text attach...

Suppose I have in my CFG (among others) two basic blocks A and B, with an edge from A to B. I need to do the following: * get the set S of live values across that edge * map each of them to another value (S->S') * replace - in B and its successors - all the uses of values in S with the mapped values (S') Does LLVM provide an easy way to do this (because I can't

Hi, Both LazyValueInfo and ScalarEvolution can calculate a constant range for an LLVM Value. I found that some times they do not agree, may be I interpreted them incorrectly For example in the following IR: bb85: ; preds = %bb85, %bb73 %tmp86 = phi i32 [ 1, %bb73 ], [ %tmp95, %bb85 ] %tmp95 = add nsw i32 %tmp86, 1 %tmp96 = icmp slt i32 %tmp95,

...: - Moving Polly to different positions in the LLVM pass pipeline (-polly-position=early vs. -polly-position=before-vectorizer). The latter option adds one large basic block, but otherwise doesn't seem to analyze the hot paths. - Setting -polly-delicm-compute-known=true and polly-delicm-overapproximate-writes=true. This doesn't seem to have effect on the hot paths. Can anyone give me some pointers on how to fix this? Or could this be a regression in Polly? Thanks! [1] https://nautilus.bjornweb.nl/files/localcolorcorrection.c [2] https://nautilus.bjornweb.nl/files/polly390-cfg.pdf [3] ht...

Hello, I thought about doing a dynamic detection of signed integer overflow for OpenCL kernels based on the generated LLVM IR. A problem seems to be that the LLVM IR does not differentiate between signed and unsigned types in general. But for instance for additions it should be possible to use the "nsw" flag as indicator that the operations involves signed types. Is this a legal

...n the LLVM pass pipeline >> (-polly-position=early vs. -polly-position=before-vectorizer). The >> latter option adds one large basic block, but otherwise doesn't seem to >> analyze the hot paths. >> - Setting -polly-delicm-compute-known=true and >> polly-delicm-overapproximate-writes=true. This doesn't seem to have >> effect on the hot paths. >> >> Can anyone give me some pointers on how to fix this? Or could this be a >> regression in Polly? >> >> Thanks! >> >> [1] https://nautilus.bjornweb.nl/files/localcolorcorrec...

...of the values with uses in S_b (optional) * LV_b <- VD_b ∩ VS_b, i.e. the live values (optional, otherwise LV_b = VD_b) * create the value mapping LV_b -> LV'_b * apply the mapping to the uses in VS_b the points marked (optional) are needed only if we don't want an overapproximation of the set of live values. To keep things simple, let's assume that b has a single predecessor. Is this correct? Any flaws? -- Carlo Alberto Ferraris <cafxx at strayorange.com <mailto:cafxx at strayorange.com>> website/blog <http://cafxx.strayorange.com> - +39 333 764...

Hello all, It seems that it is insufficient to rely on MemorySSA to correctly reorder load/stores. For example, we have this following code: v = load q store 10, p => store 10, p v = load q // This is incorrect if p and q may alias In the MemorySSA representation however, there's no syntactic dependency between load/store, because MemorySSA before transformation would look like this:

...ev at lists.llvm.org> wrote: > Since they are different static analyses there's no reason to expect them > to agree, but they should both be conservative. In other words, if you like > you can compute the intersection of the two ConstantRanges and the result > should still be an overapproximation of the values that will occur at run > time. > > John > > > > > On 07/24/2017 02:34 PM, Hongbin Zheng via llvm-dev wrote: > >> Hi, >> >> Both LazyValueInfo and ScalarEvolution can calculate a constant range for >> an LLVM Value. >> I fou...

Hi Philip, I forgot to mention that I was ignoring loop-independent dependences. If I don't I get an inconsistent, ordered, anti, loop-independent dependence and an inconsistent, ordered, flow, loop-carried dependence for example A. At the same time I get just a consistent, ordered, anti, loop-independent dependence for example B. Here's the .ll code for example A: *; Function Attrs:

...ring is allowed without any flow-sensitive analysis. >> >> What's the goal? >> Much like SSA is meant to speed up certain dataflow problems, so is >> this. Something would have to be slow to make this worth it. >> >> MemorySSA in particular is deliberately an overapproximation in LLVM >> (and GCC), because we discovered exactness is super-expensive, >> impossible, and going as far as you can buys you almost nothing in >> practice. >> However, it makes for a much faster memorydependenceanalysis (which in >> llvm is also only upwards and...

...onditions 'flattens' the loop body. Conditions can be whether a previous statement has been executed or not (control dependence) so that the original CFG can be reconstructed. Affine conditions can be directly represented in the polyhedral model, for others 'always executing' is an overapproximation and it is checked at runtime whether it is really executed. This allows more flexibility than Polly's SESE subregion macro-statement approach. Whether a condition is affine or not also has no influence on other transformations. VPlan also uses SESE in its CFG representation, but I think i...

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also