similar to: [LLVMdev] Testcases where GVN uses too much memory?

Mainline. ------------------------------ From: John Criswell Sent: Tuesday, May 03, 2011 8:34 PM To: Arushi Aggarwal Cc: LLVM Dev Subject: Re: [LLVMdev] GVN Infinite loop On 5/3/11 5:25 PM, Arushi Aggarwal wrote: Hi, GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either. Are you running with LLVM

On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1.  Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp > llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp 3.7 was released over two years ago; there have been

Hello again, Just wondering if there is a flag I can pass when compiling with llvm-gcc that can emit the llvm IR after the gvn pass (want to see the IR after dead code elimination/redundancy elimination). If so, will other passes be performed as well? I really just want to see the IR after the eliminations only, if it is at all possible. Thanks in advance, -nonpoly -- View this message in

Hi, I wonder what PRE algorithm is used for the GVN.cpp in LLVM. Any reference will be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140930/3d7f74e3/attachment.html>

Hi, I've noticed that alias analysis queries arising from GVN do not use the results from GlobalsAA. The last call to AAResultsWrapperPass::runOnFunction() before GVN does not add GlobalsAAWrapperPass due to unavailability. This leads to the alias queries from GVN not having any globals mod-ref info. Is this a known issue? and is there any way to have globals mod-ref info available for GVN?

Currently, the GVN optimization widens loads if the alignment permits it. There are some limitations that show up, as seen in example below: Initial IR: declare void @consume(i8) readonly define i8 @bar(i8* align 2 %a) { %1 = load i8, i8* %a %idx = getelementptr i8, i8* %a, i64 1 %2 = load i8, i8* %idx, align 1 call void @consume(i8 %1). ret i8 %2 } define i1 @foo(i8* %a) { entry:

Might have to do with GVN's PRE (partial redundancy elimination), which tends to increase code size. H. ----- Original Message ----- From: Abhinash Jain Sent: 09/22/13 01:17 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Why total number of store instructions increased in case of gvn with reg2mem? Below are the 4 cases out of which for the first 3 cases am able to understand the variation

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

On Wednesday 05 May 2010 12:00:18 nonpoly wrote: > Hello again, > Just wondering if there is a flag I can pass when compiling with > llvm-gcc that can emit the llvm IR after the gvn pass (want to see the IR > after dead code elimination/redundancy elimination). If so, will other > passes be performed as well? I really just want to see the IR after the > eliminations only, if

On 1/20/2017 3:19 PM, Philip Reames via llvm-dev wrote: > > If someone can produce an *IR* reproducer which they believe is > incorrect, I'm happy to take a look at the PRE code. I will not have > the time to reproduce this from C or work through the interaction of > other passes; I will only look at this if there is a bug with PRE > specific IR reproducer attached.

Hello, I've been analyzing GVN algorithm and I've found one place where it could be easily improved. Note that this is my first patch here. Please be tolerant ;) -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: gvn-load-pre.patch Type: application/octet-stream Size: 2236 bytes Desc: not available URL:

Hi all, While testing my own AA, I found it being queried for values that didn't exist previously. Luckily there's a pass built into LLVM for catching such things, "Debug-AA", and I used that to confirm that GVN does this fairly frequently. I've attached a test case that triggers the bug (reduced from Stanford/Treesort, for whatever that's worth), this is on LLVM 2.7.

Below are the 4 cases out of which for the first 3 cases am able to understand the variation on total number of store inst. But when -gvn parameters is passed (in case 4) , why does the total number of strore Instruction present on the attached file increases (instead of decrease). Please explain considering that use of -reg2mem pass is mandatory. eg. clang -emit-llvm bzip.c -c -o bzip1.bc

I find that clang is very slow compiling a C function (generated by a tool). The function contains a very large switch statement within two nested loops. From opt -time-passes, I can see that almost all the time (95%) is being spent in GVN. I cannot afford to reduce the optimization level to -O1 (which will shut off GVN) as it causes the run-time to degrade by an unacceptable factor (>2.5X).

Hello, I was investigating GVN.cpp file and I found suspicious part: 1587 bool NeedToSplitEdges = false; 1588 for (pred_iterator PI = pred_begin(LoadBB), E = pred_end(LoadBB); 1589 PI != E; ++PI) { 1590 BasicBlock *Pred = *PI; 1591 if (IsValueFullyAvailableInBlock(Pred, FullyAvailableBlocks)) { 1592 continue; 1593 } 1594 PredLoads[Pred] = 0; 1595 1596 if

Hi All, Does gvn automatically perform points-to-analysis? Thanks. George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110414/2e4f4f8a/attachment.html>

Hi, Can someone tell which algorithm is used for GVN in LLVM? -- Rekha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130928/ca06c78a/attachment.html>

On May 3, 2011, at 3:25 PM, Arushi Aggarwal wrote: > Hi, > > GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either. > > Any pointers to how to reduce the test case. Bugzilla can reduce testcases that cause infinite loops (it has a -timeout flag), I'd try it. Even if this doesn't

Hello, I was trying a basic example on LLVM GVN Hoist and output differs from what I expect. Am I missing something ? *Code* : int main() { int x = 7; int a = 0; if(a == 7){ x = 1; a = 8 * x; } else { x = 1; a = 2 * x; } return 0; } *Commands* : clang-8 -O0 -S -emit-llvm test.c opt-8 -gvn-hoist -S < test.ll *Output :* ; ModuleID = '<stdin>' source_filename =

Hi, I'm having a problem with GVN removing a load instruction that I think is needed. Dump before GVN: *** IR Dump Before Global Value Numbering *** ; Function Attrs: minsize optsize define i16 @TEST__MAIN(i16 %argc.13.par, i16** %argv.14.par) #0 { %buf.17 = alloca [10 x i16], align 1 %_tmp30 = getelementptr inbounds [10 x i16], [10 x i16]* %buf.17, i16 0, i16 0, !dbg !22 call