similar to: [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

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

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

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

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

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

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

Hi, I'm trying to optimize a pattern like this into a single i16 load: %1 = bitcast i16* %pData to i8* %2 = load i8, i8* %1, align 1 %3 = zext i8 %2 to i16 %4 = shl nuw i16 %3, 8 %5 = getelementptr inbounds i8, i8* %1, i16 1 %6 = load i8, i8* %5, align 1 %7 = zext i8 %6 to i16 %8 = shl nuw nsw i16 %7, 0 %9 = or i16 %8, %4 I came across load combine pass which is motivated

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

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

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 =

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

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transformation we agreed > that we don't want to do

Hi, On 08/07/2015 10:30 PM, Nick Lewycky wrote: [...] > Depends. What is the exact declaration of format_long? > > > In the input .ll file it is: > > ; Function Attrs: minsize optsize > define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, > i32 %x.10.par) #3 { > > which is later changed somewhere in opt to: > > ;

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from

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 =

If we do load combining at the IR level, one thing we'll need to give some thought to is atomicity.  Combining two atomic loads into a wider (legal) atomic load is not a reversible transformation given our current specification. I've been thinking about a concept I've been tentatively calling "element wise atomicity" which would make this a reversible transform by

On 08/07/2015 01:53 PM, Caldarale, Charles R wrote: >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] >> On Behalf Of Mikael Holmén via llvm-dev >> Subject: [llvm-dev] load instruction erroneously removed by GVN > >> But between the load and the alloca there is also >> call fastcc void @format_long(i16* %_tmp30, i16 10, i32 10), !dbg !22 >>

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:

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