search for: pr1255

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, > 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 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, > 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 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, 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 Bob, This has turned out to be what appears to be a very obscure binutils bug. I'm working on a test case for it now. I have a patch for Mips16 llvm which works around the issue for now. In general, pure risc architectures have no pity for compiler and toolchain developers. Mips16 is way more extreme in this way than mips32. In mips32, there is no PC register or PC relative

Hello, I have an problem where a switch with case ranges (like gcc's "case 123 ... 456:" would be fantastic for performance. Does LLVM asm plan to support a construct like this? Thanks. -- Cory Nelson

Hi all. Guys in accordance to PR1255 I need to add case-ranges support for passes listed in subject. Who can review some of these passes in nearest future? Thanks! -Stepan.