search for: overapproximated

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

Il 14/06/2011 18:17, Carlo Alberto Ferraris ha scritto: > 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

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,

Hi, Recently I was looking at the potential of optimizing through Polly. The code that I am trying to optimize [1] adjusts a picture's colors to get an Instagram-like effect. To improve code analyzability on LLVM 3.9.0, I made the following changes: - Improve SCoP detection through -polly-process-unprofitable - Enable outer loop vectorization through -polly-vectorizer=stripmine, disabling

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

Hi Johannes, Perfect, thanks! The CFG now looks very similar to what I got on LLVM 3.9.0 ([1] vs [2]). Any idea why setting -simplifycfg-sink-common=false is necessary? Similar to LLVM 5.0.1, the default for 3.9.0 is true [3], and setting it to false wasn't necessary in the latter version. [1] https://nautilus.bjornweb.nl/files/polly501-cfg-simplifycfg-sink-common.pdf [2]

From the fact that nobody is replying I guess there's no easy way to do what I asked. Can you just confirm then that the following is a meaningful way to do it? * D_b <- set of dominators of BB b * S_b <- set containing b and its successors (optional) * VD_b <- set of the values defined in D_b * VS_b <- set of the values with uses in S_b (optional) * LV_b

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:

Thanks, maybe we could use ScalarEvolution in LazyValueInfo if it is available? On Mon, Jul 24, 2017 at 1:44 PM, John Regehr via llvm-dev < llvm-dev 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

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:

On Tue, Oct 2, 2018 at 4:44 AM Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr> wrote: > > Hello Daniel, > > Thank you for the reply. > My impression was that embedding such information into MemorySSA > would be helpful for shorter compilation time > as well as people who needs this kind of information for writing optimizations, > but building time of MemorySSA also

...evel. The goal is to allow any loop transformation (eg. vectorizer) can use any dependency precision. For the polyhedral representation, we could introduce an intermediate layer that allows to plug in other intLP solvers and return approximations of the true result. Dependencies can be arbitrarily overapproximated, which inhibits transformations, but stays correct. Alternative implementations might just allow rectangles or octahedra [6] instead of polyhedra, which do not have exponential worst-case behaviours. Polly at the moment does not know register or control dependencies. I hope that adding such kind o...

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