similar to: [LLVMdev] range-analysis in Function Pass on Eclipse with CMake

dw <dw.dev.mailing at gmail.com> writes: [snip] > Everything compiles fine, but loading the pass in LLVM gives me the > following error: > >> /opt/llvm/bin/opt: symbol lookup error: ./build/lib/RangeAnalysis.so: undefined symbol: _ZN4llvm13ConstantRangeC1ENS_5APIntES1_ >> error: unable to interface with target machine > > I use LLVM 3.4svn on Ubuntu x64. >

Hi, Andrey, sorry for the delay: I made a page with the code available for download: http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html Feel free to get it, and if you need some help, I will be happy to tell you how to set the analysis up, in case the explanation in the page is not good. I also have a report describing the implementation here: (

Can't read your paper because the permission is not set. Chuck On 2/25/2011 12:16 PM, Douglas do Couto Teixeira wrote: > Hi, Andrey, > > sorry for the delay: I made a page with the code available for > download: > http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html >

Dear Douglas, Comments below. On 3/23/11 8:06 AM, Douglas do Couto Teixeira wrote: > Dear LLVM community, > > I would like to contribute to LLVM in the Google Summer of Code > project. My proposal is listed below. Please let me know your comments. > > > Adding Range Analysis to LLVM > > > > Abstract > > The objective of this work is patch our

Hi Douglas, On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: > My work is not part of the LLVM mainline yet. But I would be happy to > contribute with the code of my range analysis implementation if it can help > you in something else. We were thinking of adding VRP to LLVM too, though we were mostly interested in Patterson's approach (i.e. not connected with SSI form). It

Hi Reed, I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years). Xcode works fine as well, I started to use Xcode exclusively when I switched to OS X. The key to make this work is to

Dear LLVM community, I would like to contribute to LLVM in the Google Summer of Code project. My proposal is listed below. Please let me know your comments. Adding Range Analysis to LLVM Abstract The objective of this work is patch our implementation of range analysis into LLVM. I have a running implementation of range analysis in LLVM, but it is not currently part of the main distribution. I

Hi Oscar, On Thu, Jul 2, 2009 at 2:59 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> It might be worth to put an Eclipse CDT project file with relative >> paths to the header files in the LLVM SVN repository to make it easier >> for people to use Eclipse in the future (my project files currently >> contain absolute paths, so they're probably not useful to other

On 07/16/2013 05:21 AM, Tilmann Scheller wrote: > Hi Reed, > > I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years). > > Xcode works fine as well, I started to use Xcode

On 07/16/2013 05:21 AM, Tilmann Scheller wrote: > Hi Reed, > > I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years). > > Xcode works fine as well, I started to use Xcode

Yeah, that change is completely unrelated, that is about correctness, this is about optimization. I'm working on a proposal to just fix assume at some point to deal with the former issue. The problem with this testcase is that all the ways assume is propagate expect the variable in the assume to later be used. <This is the main way assume constants are propagated> bool

Hmmm... why? Duncan Sands wrote: > Hi Stepan, > >> Well... each case is represented as pair<BB, vector<Range> >. Right? > > after thinking about this some more I think you are right to not use > ConstantRange, and instead to build your own set abstraction. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing

Hi, I have a question about ConstantRange::sub(const ConstantRange &Other) at lib/Support/ConstantRange.cpp:524. The code computes the new bounds as follows. APInt NewLower = getLower() - Other.getLower(); APInt NewUpper = getUpper() - Other.getUpper() + 1; Could someone explain this to me? I was expecting something like APInt NewLower = getLower() - Other.getUpper() + 1; APInt

Hello. This question has come up in https://reviews.llvm.org/D70043 There, i'm teaching ConstantRange how no-wrap flags affect the range of `mul` instruction, with end goal of exploiting this in LVI/CVP. There are certain combinations of ranges and no-wrap flags that result in always-overflowing `mul`. For example, `mul nuw nsw i4 [2,0), [4,0)` always overflows:

Sure. I will submit a patch. BTW, what's the difference between the bounds I was expecting APInt NewLower = getLower() - Other.getUpper() + 1; APInt NewUpper = getUpper() - Other.getLower(); and the two you mentioned NewLower = Lower - (Upper-1) NewUpper = (Upper-1) - Lower + 1 They look equivalent to me. Did I miss anything? Thanks. - xi On Jun 22, 2011, at 2:39 PM, Nick Lewycky

Hi, Duncan. unionWith result is differs from set union, since it produces single set always while set operations may produce two sets. E.g.: For ranges [1, 5) and [10,15) unionWith produces [1,15), while set union should just keep these sets without changing, probably with indication that sets are not intersected. Implementation of set union is simple though. The "symmetric

On Mon, Jul 24, 2017 at 2:29 PM, John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 7/24/17 3:16 PM, Hongbin Zheng via llvm-dev wrote: > >> Thanks, maybe we could use ScalarEvolution in LazyValueInfo if it is >> available? >> > > This should be fairly easy to try, if you want to propose a patch and run > some experiments. The question is

Maybe. It may not fix it directly because you never use %1 or %2 again. I haven't looked to see how good the lookup is. On Fri, Jun 10, 2016, 3:45 PM Josh Klontz <josh.klontz at gmail.com> wrote: > Thanks Daniel, with that knowledge I think I can at least work around the > issue in my frontend. > > Ignoring GVN for a second though, and just looking at Early CSE, it seems

Hi Stepan, > Hmmm... why? because you basically want pairs (set, destination) where set could be a arbitrary set of integers. As in practice these sets are a union of a small number of intervals, the set abstraction should efficiently represent unions of intervals, but that's more of an optimization than anything else. Probably for the needs of switch lowering you will need to expose the

Well... each case is represented as pair<BB, vector<Range> >. Right? We need "union" for optimal case building. And we need support "difference" if we decided that some ranges or numbers in case will never used (in some optimization passes it happens sometimes). -Stepan 26.04.2012, 15:18, "Duncan Sands" <baldrick at free.fr>: > Hi Stepan, >