similar to: LazyValueInfo vs ScalarEvolution

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

The current BasicCallGraph will miss call sites like this: %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) ; <i8*> [#uses=1] Here the direct user of @find_ispell is a ConstantExpr. I added several lines of code to address this case. Below is the output of command: svn diff lib/Analysis/IPA/CallGraph.cpp Attached is LLVM asm files with such function calls.

On Thu, 12 Jul 2007, Zhongxing Xu wrote: > The current BasicCallGraph will miss call sites like this: > %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) > ; <i8*> [#uses=1] > > Here the direct user of @find_ispell is a ConstantExpr. > I added several lines of code to address this case. > Below is the output of command: svn diff

I am doing inter-procedural static analysis, so I need to do DFS of call graph. llvm-gcc sometimes generates this kind of call instruction, which cause the call graph to be incomplete. But thanks for your information, instcombine really solves the problem. On 7/17/07, Chris Lattner <sabre at nondot.org> wrote: > > On Thu, 12 Jul 2007, Zhongxing Xu wrote: > > The current

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

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

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.

I found a case where GVN seems to miscompile an OpenCL program. What I am trying to figure out is given a bitcode file, how can I reduce it to a simpler case with bugpoint when I don't have a valid reference compiler available. Thanks for any tips, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL:

Great, thanks! How much work do you think it will take to bring it up to date with the LLVM IR, except *ignoring* first-class structs and arrays for now? I believe llvm-gcc does not generate those in most cases and we can do a lot without supporting those. What else is missing relative to the current LLVM IR? Thanks, --Vikram Associate Professor, Computer Science University of

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Tue, 17 Jul 2007, Zhongxing Xu wrote: > I am doing inter-procedural static analysis, so I need to do DFS of call > graph. llvm-gcc sometimes generates this kind of call instruction, which > cause the call graph to be incomplete. > > But thanks for your information, instcombine really solves the problem. Happy to help. You'll probably find that other optimizations help as

In my server log, I am seeing this error message that is raised in activesupport. 2013-08-12T23:06:08.932580+00:00 app[web.2]: SyntaxError (/app/vendor/bundle/jruby/1.9/gems/activesupport-4.0.0/lib/active_support/callbacks.rb:374: syntax error, unexpected tRPAREN 2013-08-12T23:06:08.932580+00:00 app[web.2]: 2013-08-12T23:06:08.932580+00:00 app[web.2]: def () value = nil

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops

Hello, If I run clang on the following code: void func(unsigned n) { > for (unsigned long x = 1; x < n; ++x) > dummy(x); > } I get the following llvm ir: define void @func(i32 %n) { > entry: > %conv = zext i32 %n to i64 > %cmp5 = icmp ugt i32 %n, 1 > br i1 %cmp5, label %for.body, label %for.cond.cleanup > for.cond.cleanup:

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 12:21 PM, Alexandre Isoard via

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

Hi, I am working on some changes to LazyValueInfo and I wanted to see how it was used in existing passes. Currently I can see that Jump Threading and Correlated Value Propagation are the 2 passes that use LazyValueInfo. However on the LLVM docs page of passes (http://llvm.org/docs/Passes.html <http://llvm.org/docs/Passes.html>), Correlated Value Propagation is not mentioned as a pass. Does

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is