similar to: [LLVMdev] global constant integer and pointer

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

I'm attempting to modify a parser generator to emit LLVM code instead of C. So far the experience has been trivial, but I am now running into an error regarding labels that I can't seem to solve. Situation 1: A label is used immediately after a void function call (l6 in this case): <snip> %tmp26 = load i32* @yybegin, align 4 %tmp27 = load i32* @yyend, align 4 call void

The following code compiles for Sparc prior to version 119382 but causes a llc to hang in version 119382 and later. I glanced at it but haven't figure it out yet. I figure I'd ping the list to see if it's an obvious fix to someone else. define void @test(i16 %di, i32 %L_num, i32 %tmp1, i16* %P) { %X = shl i16 %di, 1 ; <i16> [#uses=1] %tmp28 = shl

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

Hi, I'm using LLVM 2.7 right now, and I found "opt -std-compile-opts" has missed some opportunities for optimization: define void @spa.main() readonly { entry: %tmp = load i32* @dst-ip ; <i32> [#uses=3] %tmp1 = and i32 %tmp, -16777216 ; <i32> [#uses=1] %tmp2 = icmp eq i32 %tmp1, 167772160 ; <i1> [#uses=2]

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

Hello, I've come across another example: I'm compiling with clang -S -emit-llvm -std=gnu99 -O3 clang version 2.9 (trunk 118238) Target: x86_64-unknown-linux-gnu Thread model: posix I take the code: int loops(int x) { int ret = 0; for(int i = 0; i < x; i++) { for(int j = 0; j < x; j++) { ret += 1; } } return ret; } and the

Hey Duncan, hey everybody else, I just stumbled upon a problem in the latest llvm-gcc trunk which is related to my previous problem with the 64bit ABI and structs: Given the following code: struct float3 { float x, y, z; }; extern "C" void __attribute__((noinline)) test(float3 a, float3* res) { res->y = a.y; } int main(void) { float3 a; float3 res; test(a,

On Thu, Jan 15, 2015 at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 15 January 2015 at 13:10, Daniel Berlin <dberlin at dberlin.org> wrote: > >> Yes. >> I've attached an updated patch that does the following: >> >> 1. Fixes the partialalias of globals/arguments >> 2. Enables partialalias for cases where nothing has been unified to

I'm not exactly thrilled about the size of this diff -- I'll happily break it up into more manageable bits later today, because some of it is test fixes, another bit is a minor bug fix, etc. Important bit (WRT ConstantExpr): moved the loop body from buildGraphFrom into a new function. The body has a few tweaks to call constexprToEdges on all ConstantExprs that we encounter.

From: Sebastien Boeuf <sebastien.boeuf at intel.com> On PCI the shm regions are found using capability entries; find a region by searching for the capability. Signed-off-by: Sebastien Boeuf <sebastien.boeuf at intel.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert at redhat.com> Signed-off-by: kbuild test robot <lkp at intel.com> Acked-by: Michael S. Tsirkin <mst

Hello. I have a problem which is quite basic for array optimization, amd I wonder whether I am missing something, but I could not find the LLVM pass that does it. Consider the following code snippet: int test() { int mat[7][7][7]; int i,j,k,sum=0; for(i=0;i<7;i++){ for(j=0;j<7;j++){ for(k=0;k<7;k++){ sum+=mat[i][j][k]^mat[i][j][k^1]; } } } return

Hi, I have this piece of code: tm = local ? localtime(&curr) : gmtime(&curr); if (!tm) return NULL; which translates into something like: ---------------------------------------------- entry: %iftmp.0 = alloca %struct.tm*, align 8 %tm = alloca %struct.tm*, align 8 ... // Declares iftmp.0 as iftmp.0 call void @llvm.dbg.declare( { }* %iftmp.0, { }* bitcast

Hi Ralf, > llvm-gcc -c -emit-llvm -O3 produces this: > > %struct.float3 = type { float, float, float } > define void @test(double %a.0, float %a.1, %struct.float3* nocapture > %res) nounwind noinline { > entry: > %tmp8 = bitcast double %a.0 to i64 ; <i64> [#uses=1] > %tmp9 = zext i64 %tmp8 to i96 ; <i96> [#uses=1] >

Hi, While playing around on the LLVM, I tried this code: int sum(int n) { if (n == 0) return 0; else return n + sum(n-1); } and this is what "llvm-gcc -O2" gave me: define i32 @sum(i32 %n) nounwind { entry: %tmp215 = icmp eq i32 %n, 0 ; <i1> [#uses=1] br i1 %tmp215, label %bb10, label %tailrecurse.bb10_crit_edge tailrecurse.bb10_crit_edge: ; preds =

David Peixotto <dmp <at> rice.edu> writes: > I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I rechecked this and am I actually seeing the same results as you. I think I must have made a stupid mistake in my tests before - sorry for the noise. However, I found that we have a phase ordering problem which is preventing us getting as much

Yes. I've attached an updated patch that does the following: 1. Fixes the partialalias of globals/arguments 2. Enables partialalias for cases where nothing has been unified to a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to

I'm attempting to instrument virtual function calls in my code. After each virtual call I'm calling my own registerMethod function, with an integer marking the location of the call and a pointer to the function that was called. However, and this is where I get confused, the function pointer doesn't match any of the functions in my module. I'd hoped to call

I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I'm running on Mac OS X 10.6. I have an apple supplied llvm-gcc and a self compiled llvm 2.8. When I run $ llvm-gcc -emit-llvm -S M.c $ opt -O2 M.s | llvm-dis I see that: 1. Tail recursion has been eliminated from wf 2. The accesses to sp have been promoted to registers 3. The loop has