similar to: [LLVMdev] flow sensitive context sensitive pointer analysis

Hi, I am looking for some flow-sensitive (context-insensitive) alias analysis algorithm implemented in LLVM. (I use LLVM 3.9, hope to switch to 4.0 soon.) As far as I know, none of the built-in analysis (basicAA, globals-modref, andersAA, etc.) is intended to be flow-sensitive. So I searched and came across these two 1. https://github.com/unsw-corg/SVF by Yulei Sui (for LLVM 3.8) 2.

Perhaps by "value" you mean points-to set? Either way, flow-sensitivity can only give you more precise -- but still not necessarily exact -- answers. Yours, Andrey === Compiler Architect NXP On Fri, Mar 10, 2017 at 6:39 PM, Flamedoge via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > For a given argument of a call instruction in the cfg: Where does the > value of

Hi I have the feeling, that the argument stringsAsFactors has no impact in the function expand.grid: a <- c("PR", "NC", "A2", "BS") b <- c(1, 0.5, 0.25, 0.125, 0.0625, 0.03125) class(expand.grid(css, fscs, stringsAsFactors=FALSE)[[1]]) [1] "factor" class(expand.grid(css, fscs, stringsAsFactors=TRUE)[[1]]) [1] "factor" Also, when

Hello, I found some code within the pool allocation project to identify parallelizable function calls. Unfortunately the functionality isn't part of the current release of poolalloc (in release 14 it was). My intention is to estimate the parallelization-potential of sequential applications concerning coarse-grained parallelism. Can you tell me... 1. Why are classes of pollalloc, like

Hello, I want to do points-to anlysis in llvm IR. I want it to be path sensitive, which means that when I print out the result, I need append the condition for the "May" Points-to. I plan to using symbolic execution to achieve this goal. Are there any tools in llvm, or stand-alone tools to solve the symbolic equation. Thank you! ----Peter Chang -------------- next part

Am 19.04.2011 um 16:44 schrieb John Criswell: > On 4/19/11 5:57 AM, Andreas Wilhelm wrote: >> >> Hello, >> >> I found some code within the pool allocation project to identify parallelizable function calls. >> Unfortunately the functionality isn't part of the current release of poolalloc (in release 14 it was). > > Can you tell me in what file(s) this

I would suggest you take a look at KLEE, PAGAI and GiNaC. The first two are LLVM-based tools that do symbolic manipulation (of sorts) and the last is a C++ library for doing symbolic computation which is quite easy to use with an RTTI build of LLVM. If you can give us an example of what symbolic equation you might be trying to "solve", I'm sure we can narrow it down or suggest

On 4/19/11 5:57 AM, Andreas Wilhelm wrote: > Hello, > > I found some code within the pool allocation project to identify > parallelizable function calls. > Unfortunately the functionality isn't part of the current release of > poolalloc (in release 14 it was). Can you tell me in what file(s) this is implemented? I wasn't aware that the poolalloc project had such an

On 04/20/2011 08:05 AM, Andreas Wilhelm wrote: > Am 19.04.2011 um 16:44 schrieb John Criswell: > >> On 4/19/11 5:57 AM, Andreas Wilhelm wrote: >>> Hello, >>> >>> I found some code within the pool allocation project to identify >>> parallelizable function calls. >>> Unfortunately the functionality isn't part of the current release of

I'm not quite understanding how one would use the existing alias analysis framework to represent a flow-sensitive analysis. Let's say I have a load and a store and I want to determine whether the load loads from the same place the store stores to. Today we'd do something like this: AA.alias(load->getPointerOperand(), /* get the size */ store->getPointerOperand()), /*

On Aug 18, 2008, at 3:19 PM, David Greene wrote: > I'm not quite understanding how one would use the existing alias > analysis > framework to represent a flow-sensitive analysis. Yep, the current infrastructure isn't set up to support this. I haven't seen a real world case where flow sensitive AA is useful. Normally, the conversion to SSA form is sufficient. Can you

On Wednesday 20 August 2008 14:07, Vikram S. Adve wrote: > At Illinois, we are working on a parallelizing compiler but we're at > an extremely early stage. We too will need a dependence analysis > interface that can support fairly aggressive analysis, including > strong tests, direction vectors, perhaps distance vectors, and > dependence breaking conditions. We were going to

On Aug 22, 2008, at 9:53 AM, Dale Johannesen wrote: >> >> C has a way to express this: signed integers are defined to never >> overflow, > > More precisely, signed integer overflow is undefined behavior, which > gives the compiler great latitude. > Assuming this will never happen and doing optimizations on that basis > is valid, but so are other things. > An

On Aug 22, 2008, at 4:49 PM, John Regehr wrote: > Has anyone quantified the optimizations afforded by undefined signed > overflow? I'd expect that the benefits are minimal for most codes. In most cases, I agree. But for codes that depend heavily on dependence analysis, I would think that being conservative with index expressions would really kill any disambiguation capability and

> before and it hurts about 3-5 without high level loop > opts/vectorization on. With them on, they do roughly nothing in the > presence of -fwrapv because you can't determine bounds of any non > trivial loop. Very interesting, thanks! Before hearing this I'd have said that Java-style overflow is the right language design, but if this makes loop optimizations impossible

On Sun, Aug 24, 2008 at 6:28 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Aug 24, 2008 at 2:46 PM, Wojciech Matyjewicz > <wmatyjewicz at fastmail.fm> wrote: >>> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? >> >> I think it is not possible in general, but I

>> One nit-pick, I see that some of the interfaces use tons of parameter, >> which is something I'd like reduce for ease of use. > >Right. It was my concern as well, but I eventually decided to write it >this way. Feel free to change it. > As we are speaking about modifying the lib, here are two things I would like to modify/add in it: - Replacing depedency

>Polyhedral representations are powerful but somewhat expensive to >construct and simple dependence tests don't construct them. Forcing >all dependence test results to go through them would be overkill. >Also, many loop transforms, e.g., loop interchange, don't need the >polyhedral info, just direction vectors. You could instead provide >both direction

On Aug 22, 2008, at 4:27 PM, David Greene wrote: > Exactly right. One of my first jobs here was to fix a bunch of > overflow > problems exposed by optimization. It's now become a tradition to > give this task to any new optimizer employee. :) But that sounds like Cray is being fairly conservative in treating overflow problems as errors during optimization. Is that

On Aug 29, 2008, at 10:15 AM, Matthieu Delahaye wrote: > Hi, > > On Fri, 2008-08-29 at 09:24 -0700, Devang Patel wrote: > [...] >> - Put various tests, DeltaTest, in lib/Analysis folder. The >> transformation pass does not need to see these details. > > > I believe some low-level tests should actually not be implemented as a > separate Analysis but placed into