similar to: [LLVMdev] ConstantRange in PR1255

Hi Stepan, > Hi Duncan. I have strange problems with you mailbox, my posts are lost sometimes on this way. OK, sorry about that. Do you have any details? > I just want to duplicate answer on your question in this thread: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120305/138785.html > > ConstantRange has a little bit another purposes. It is not a classical

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

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

Hi Stepan, > unionWith result is differs from set union, since it produces single set always > while set operations may produce two sets. this is true, but that's inevitable if the result is to be a single ConstantRange. You can of course define methods that returns a pair of ConstantRanges and does what you want. But why do you need these methods anyway? A "switch" is

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

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

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

Thanks, I think you've found a serious bug! Would you be willing to fix it? Please add a test to unittests/Support/ConstantRangeTest.cpp and then mail llvm-commits with the patch to fix it and add the test. On 20 June 2011 23:09, Xi Wang <xi.wang at gmail.com> wrote: > Hi, > > I have a question about ConstantRange::sub(const ConstantRange &Other) at >

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

On 22 June 2011 12:51, Xi Wang <xi.wang at gmail.com> wrote: > 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) -

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:

I've been doing some digging in this area (scev, wrapping arithmetic), learning as much as I can, and have reached a point where I'm fairly confused about the semantics of nuw in scalar evolution expressions. Consider the following program: define void @foo(i32 %begin) { entry: br label %loop loop: %idx = phi i32 [ %begin, %entry ], [ %idx.dec, %loop ] %idx.dec = sub nuw i32

I've addressed a "TODO" in ConstantRange and several in its unit test by implementing a stricter "multiply" method (it had been returning a "full" set for anything that wasn't "empty", which broader than necessary) and updated the unit test to match, but I'm not completely confident that I understand ConstantRange and APInt and was hoping someone

On Jul 10, 2009, at 2:03 PM, Ryan Flynn <parseerror at gmail.com> wrote: > I've addressed a "TODO" in ConstantRange and several in its unit test > by implementing a stricter "multiply" method (it had been returning a > "full" set for anything that wasn't "empty", which broader than > necessary) > and updated the unit test to

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

On Fri, Jul 10, 2009 at 8:35 PM, Dan Gohman<gohman at apple.com> wrote: > > > On Jul 10, 2009, at 2:03 PM, Ryan Flynn <parseerror at gmail.com> wrote: > >> I've addressed a "TODO" in ConstantRange and several in its unit test >> by implementing a stricter "multiply" method (it had been returning a >> "full" set for

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 Ryan, In this case there already is an implementation for this, it's just hard to find being in the internals of the LoopVR pass. I'm planning to pull the multiply and udiv support out of there. Your patch looks good but beyond what Dan mentioned you have a bug calculating NewUpper: the constant ranges are half-open intervals where "[5, 10)" includes the value 9 but not

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