similar to: [LLVMdev] generate llvm.assume calls in GVN?

On 15 January 2015 at 10:49, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Jan 15, 2015 at 10:30 AM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> Would it be wrong to generate the llvm.assume IR suggested below? in GVN? >> > > I think so... Because: > > One very small tweak you could make would be to add an llvm.assume inside

Hi, I'm compiling a large code base that uses tagged data, with the tag in the two lowest bits. I.e. ints are shifted two steps to the left and have 2 in the tag bits, pointers have 0 in the tag bits, etc. When I compile the code, I notice that there are places where -O3 doesn't remove unnecessary tag bit tests and manipulations, when they are performed with bitwise manipulation (which

Hi, All: I have a testcase which produced incorrect result, it's caused by the combination of nsw flag and ExtLdPromotion, I am leaning to say Clang set nsw flag incorrectly, but please let me know if I was wrong. Here is the reduced testcase: long long foo(int *a) { long long c; c = *a * 1405; return c; } Clang emitted the following IR (It is done by EmitMUL() in

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

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 =

Hi all, I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { entry: call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) ret

Hello, In some of our internal benchmarks, I observe that LLVM performs worse than GCC because LLVM fails to perform PRE when GCC can. I hope this problem goes away when NewGVN equipped with PRE, and wonder if anyone has an idea about the status of PRE on top of NewGVN. Thanks! Best, Taewook -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: > We've got the following test case: > > > class A { > public: >   int x; >   A(int x) : x(x) {} >   int hoo() {return 4;} >   virtual int foo() {return x;} >   virtual int goo() {return foo()+10;} >   virtual int operator+(A &a) { >     return x + a.x; >   } > };

Hi Daniel, Thank you for your detailed reply, and thank you for working on GVNPRE. I’d more than happy to test/evaluate it with our benchmark once it is ready. Please let me know if you need any help. Thanks, Taewook From: Daniel Berlin <dberlin at dberlin.org> Date: Tuesday, April 4, 2017 at 6:13 PM To: Taewook Oh <twoh at fb.com> Cc: "llvm-dev at lists.llvm.org"

Hi Daniel, Got it. If that's the case, can I implement it under the guidance of your insights/prototype? I think I can spend more time on implementation. Thanks, Taewook ________________________________ From: Daniel Berlin <dberlin at dberlin.org> Sent: Tuesday, April 4, 2017 9:41:30 PM To: Taewook Oh Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [NewGVN] Plan for GVNPRE? Of

We've got the following test case: class A { public: int x; A(int x) : x(x) {} int hoo() {return 4;} virtual int foo() {return x;} virtual int goo() {return foo()+10;} virtual int operator+(A &a) { return x + a.x; } }; class B : public A { public: B(int x) : A(x) {} int hoo() {return 2;} virtual int foo() {return A::foo()*2;} }; int main() { A* a = new A(1);

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

As you may have noticed, we released a 64b S4 chip that runs an ILP32 variant of the AArch64 ABI, and now we'd like to upstream that work. I've pushed preliminary patches to https://github.com/TNorthover/llvm-project/pull/1/commits (arm64_32 branch in that repo) to accompany this RFC. The changes divide fairly neatly into three categories. First, there's AArch64 ILP32 support, which

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*

Hi, i have the following code: define internal %"struct.dexter::ConditionConstant"* @_ZN6dexter18BinaryConditionAdd8evaluateEv5(%"class.dexter::BinaryConditionAdd"*) { entry: %1 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %0, i32 0, i32 0, i32 1 %2 = load %"class.dexter::BaseCondition"** %1, align 8 %3 = bitcast

Hello, I found that GVN doesn't promote identical sequence of instructions in if and else branch to their common predecessors. For example, for the following code snippet pred: … br i1 %cmp, label %if, label %else if: %incdec.ptr.1 = getelementptr inbounds i8, i8* %ptr, i64 1 %cast1 = ptrtoint i8* %incdec.ptr.1 to i64 … else: %incdec.ptr.2 = getelementptr inbounds i8, i8* %ptr,

Hi, All, Suppose I have a very simple code like this and variable 'a' is a global variable: *************************************************************************** *double ** a;* *int main(){* * a[5][10] = 0.1;* * a[5][20] = 0.5;* * return 0;* *}* *************************************************************************** Then I can get the IR without any optimization like

Hi All, I've encountered an issue where tail merging MIs is causing a problem with the post-RA MI scheduler dependency analysis and I'm not sure of the best way to address the problem. In my case, the branch folding pass (lib/CodeGen/BranchFolding.cpp) is merging common code from BB#14 and BB#15 into BB#16. It's clear that there are 4 common instructions (marked with an *) in BB#14