similar to: [LLVMdev] review request for patch

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

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

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

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

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

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 >

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

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

On 1/18/17 3:55 PM, Davide Italiano via llvm-dev wrote: > On Tue, Jan 17, 2017 at 6:02 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: >> Hi, >> >> Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100%

Hello, I currently write my own LLVM (function) pass and intend to use the following project to enable the use of range analysis information in my code: https://code.google.com/p/range-analysis/. Since I use Eclipse (with CMake) to build LLVM I did the following: 1. Provide each subfolder with a CMakeLists.txt (add_llvm_loadable_module). 2. Re-create the CMake config (cmake ../llvm -G

Ah but how did you compile the clang-4.0 you were using? Does it run faster if you compile it with clang-4.0? :) On Fri, Jan 20, 2017 at 4:09 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On this topic, I just tried to build ToT with clang-3.9.1 and clang-4.0 > and the total time to complete `ninja clang` on this machine went from > 12m54s to

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

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

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

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:

Hi Duncan. I have strange problems with you mailbox, my posts are lost sometimes on this way. 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 range. Yes it has Lower and Upper, but "sub" and "add" operations

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

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