similar to: [LLVMdev] GVN Infinite loop

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] GVN Infinite loop"

2011 May 04
0
[LLVMdev] GVN Infinite loop
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
2011 May 03
3
[LLVMdev] GVN Infinite loop
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. THanks, Arushi GVN iteration: 8 GVN WIDENED LOAD: %0 = load i8* getelementptr inbounds (%struct.CHESS_POSITION* @search, i64 0, i32 23), align 2, !dbg !875 TO: %1 = load i16* bitcast (i8*
2016 Jun 30
0
Optimizations hindered by GVN widening
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:
2011 Feb 24
1
[LLVMdev] Get Element Ptr inst
Thanks John. You are right. Is this also true for constant GEP expressions? Do they also create a pointer to the calculated type? The language manual does not state so explicitly. Arushi On Thu, Feb 24, 2011 at 10:47 AM, John Criswell <criswell at illinois.edu>wrote: > On 2/24/11 10:39 AM, Arushi Aggarwal wrote: > >> Given 2 GEPs as follows, >> >> %tmp124 =
2011 Feb 24
0
[LLVMdev] Get Element Ptr inst
On 2/24/11 10:39 AM, Arushi Aggarwal wrote: > Given 2 GEPs as follows, > > %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, > i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] > %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, > !dbg !1051 ; <i16*> [#uses=1] > > can I replace the 2nd one with > > %tmp126 = getelementptr
2010 Apr 21
0
[LLVMdev] Function pointers bitcasted to varargs
Do you compile this as C? In C, unlike in C++, empty parenthesis do not mean "no arguments", they mean "no prototype", which is typically treated the same way as varargs in calling conventions. To declare function with no arguments do typedef void (*FP)(void); Eugene On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Hi all, > >
2015 Aug 07
2
load instruction erroneously removed by GVN
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
2010 Dec 13
1
[LLVMdev] How can I determine safely if a CallSite is "live" in a DSGraphs context
Hi, I believe shouldHaveNodeForValue() should return false for ConstantPointerNullValue. Fixed in r121707. Arushi On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit <kevin.streit at googlemail.com>wrote: > I'm using BUDataStructures... But I tried LocalDatastructures and it didn't > work either... > On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at
2016 Jul 20
2
load instruction erroneously removed by GVN v2
Hello to whom this may concern, Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value. I am using LLVM-3.5, but the problem has been observed upto 3.8. To illustrate the problem, define i32 @main scalar.ph: <initialize [80 x i16] %dest> ... preheader: %index=0 br test, loop1, bb2
2016 Sep 29
2
Load combine pass
> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko via llvm-dev wrote: > > One of the arguments for doing this earlier is inline cost > > perception of the original pattern. Reading i32/i64 by bytes look much > > more expensive than it is and can prevent inlining of interesting > >
2016 Jul 20
2
load instruction erroneously removed by GVN v2
Thanks for quick reply Daniel, I tried to make a simple C testcase, but could not reproduce the same condition with output from Clang. I suppose I could modify the C code to make it look similar with TBAA's; I may be able to provide this by eod. > store %ptr above the load. My mistake; I was referring to the store $lcssa in bb2. Looking at the C source code, it should definitely alias
2011 Feb 24
2
[LLVMdev] Get Element Ptr inst
Given 2 GEPs as follows, %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, !dbg !1051 ; <i16*> [#uses=1] can I replace the 2nd one with %tmp126 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, i64 0, i64 0 ; <i16*> When I try to
2011 Feb 22
0
[LLVMdev] Clone a function and change signature
On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > Hi, > > I want to clone a given function, and add an argument to it. I then > want to add a call to that new function. I have a callInstruction CI, > which I want to transform to call this new function, and to take a new > argument. If I understand correctly, you're cloning the function first and then adding a new argument to
2016 Jul 20
2
load instruction erroneously removed by GVN v2
before inlining all 20005 after inlining somewhere here changed made it NoAlias after Global Variable Optimizer 20014 20373 20255 20372 20254 before GVN 19993 20011 19991 20010 20030 It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in
2011 Feb 23
0
[LLVMdev] LLVMdev Digest, Vol 80, Issue 37-Help to unsubscribe
Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at
2010 Apr 21
2
[LLVMdev] Function pointers bitcasted to varargs
Hi all, I had the following function that used function pointers with void arguments, typedef void (*FP)(); void foo() { printf("hello world from foo\n"); } int main() { FP fp; fp = foo; (*fp)(); } The corresponding bitcode, with no optimizations is target datalayout =
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;
2016 Sep 28
4
Load combine pass
One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other
2011 May 12
0
[LLVMdev] Machine Function Pass
On 5/12/11 11:46 AM, Arushi Aggarwal wrote: > I tried > llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so > --help > > But this does not show my pass. It says it is an unknown command line argument. I'm assuming you've looked at other MachineFunctionPass'es and have registered yours in the same way that they do. I don't think
2017 Jan 13
4
Wrong code bug after GVN/PRE?
Hi, I've stumbled upon a case where I think gvn does a bad (wrong) optimization. It's a bit messy to debug though so I'm not sure if I should just write a PR about it a let someone who knows the code look at it instead. Anyway, for the bug to trigger I need to run the following passes in the same opt invocation: -sroa -instcombine -simplifycfg -instcombine -gvn The problem