search for: i32s

On Fri, Sep 21, 2012 at 3:08 PM, Welson Sun <welson.sun at gmail.com> wrote: > OK, with the restrict type qualifier, it is a little bit better: > > The IR's function signature becomes: > define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind > { > > Now the AA result: > Function: foo: 13 pointers, 0 call sites > NoAlias: i32* %a,

Here is the result of running mem2reg then basicaa, it is even worse: (%a should be alias to %0, and partial alias to %3) opt -mem2reg -basicaa -aa-eval -print-all-alias-modref-info < foo.s > /dev/null Function: foo: 6 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c PartialAlias: i32* %1, i32* %a NoAlias:

OK, with the restrict type qualifier, it is a little bit better: The IR's function signature becomes: define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind { Now the AA result: Function: foo: 13 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c NoAlias: i32* %a, i32** %a_addr NoAlias:

Can you give an example? And is this limited to C (not C++) only? On Fri, Sep 21, 2012 at 2:52 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > I think you may add restrict type qualifier.**** > > ** ** > > Sam**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Welson Sun > *Sent:* Friday,

Hi, LLVM front end is taking a user defined type of [21 x { i32, i32, i32, [8 x i32] }] and converting it to the structurally equivalent type { { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32,

On 4 February 2013 18:25, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > For cases where this approach breaks really badly we could consider adding > a specialized api or parameters (like the type of a user/use). But we > should do so only as a last resort and backed by actual code that would > benefit from doing so. > Very sensible, more or less what I had in

Hi, I am trying to understand LLVM vectorization implementation and was looking into both loop and SLP vectorization. test case 1: *int foo(int *a) {int sum = 0,i;for(i=0; i<16; i++) sum += a[i];return sum;}* This code is vectorized by loop vectorizer where we calculate scalar loop cost as 4 and vector loop cost as 2. Since vector loop cost is less and above reduction is legal to

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

Hi Nadav, Thanks for the quick reply !! Ok, so as of now we are lacking capability to handle flat large reductions. I did go through function vectorizeChainsInBlock() (line number 2862). In this function, we try to vectorize if we have phi nodes in the IR (several if's check for phi nodes) i.e we try to construct tree that starts at chains. Any pointers on how to join multiple trees? I

Hi, I haven't been able to reproduce this problem on a smaller test and the original source code is from another virtual machine's IR. What I found out was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. This format is not dealt with in the ARMCodeEmitter.cpp and that's the problem I'm facing. The triple I'm using is

Thank you for the hint. I adjusted the code and it works: The code after replacing inttoptr with getelementptr: define { i32, i32, i8* } @test(i32 %foo, i32 %bar, i8* %sp) { entry: ; push foo (On "stack") %sp_1 = getelementptr i8, i8* %sp, i32 -4 %sp_1_ptr = bitcast i8* %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align 4 ; push bar %sp_2 = getelementptr i8, i8* %sp_1,

Hello, I am trying to emulate the "stack" as like on x86 when using push/pop so afterwards I can use LLVM's optimizer passes to simplify (reduce junk) the code. The LLVM IR code: define { i32, i32, i32 } @test(i32 %foo, i32 %bar, i32 %sp) { ; push foo (On "stack") %sp_1 = sub i32 %sp, 4 %sp_1_ptr = inttoptr i32 %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align

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

As Sanjay noted in D31426<https://reviews.llvm.org/D31426#712701>, InstructionSimplify is missing the following simplification: This function: define <4 x i32> @splat_operand(<4 x i32> %x) { %splat = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer %shuf = shufflevector <4 x i32> %splat, <4 x i32> undef, <4 x i32>

Hello, i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? My code looks something like this: //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 const char* const TARGET_DATA_LAYOUT =

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

Hi, I've been playing around with the SLPVectorizer trying to get it to vectorize this simple program: define void @vector(i32 addrspace(1)* %out, i32 %index) { entry: %0 = alloca [4 x i32] %x = getelementptr [4 x i32]* %0, i32 0, i32 0 %y = getelementptr [4 x i32]* %0, i32 0, i32 1 %z = getelementptr [4 x i32]* %0, i32 0, i32 2 %w = getelementptr [4 x i32]* %0, i32 0, i32 3

Dear LLVM, I would like to understand how to improve the LLVM alias analysis accuracy. I am currently using llvmgcc 2.9 and llvm 3.0. Here is the C code: void foo(int a[SIZE], int b[SIZE], int c[SIZE]) { for(int i=0; i<SIZE; i++) c[i] = a[i] + b[i]; } Here is the IR: target datalayout =

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

Hi Guillermo, I’m unable to reproduce the error you’re seeing with your bitcode input. “llc –mtriple armv7a-unknown-linux-gnueabi –O3” succeeds. What are you using to reproduce, and what version? Cheers, James From: Guillermo Perez [mailto:gaperez64 at gmail.com] Sent: 20 February 2012 11:32 To: James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] ARM opcode format Hi, I haven't