similar to: [LLVMdev] target datalayout defintion

You can compile an empty C source code with clang -S -emit-llvm and copy the data layout from there. 2011/10/27 Seb <babslachem at gmail.com> > Hi all, > > Can someone give me advice on what should be a good definition of target > datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? > Shall I use a different definition for a cortex-A9 without neon ? > Thanks for

I tried bu clang seems to support only target on which it has been compiled. If I use: with clang -S -emit-llvm t.c -o t.ll I've got following file for t.ll ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple =

While trying to find a solution for this bug http://llvm.org/bugs/show_bug.cgi?id=11235 , I came to the conclusion that the following things can happen while optimizing: - after gvn, I get new constants which are inserted into br and add/sum/..., so there should be at least one more jump-threading and/or instsimplify - after instsimplify, I get new constants which are inserted into br, so there

If you run with -vectorize instead of -bb-vectorize it will schedule the cleanup passes for you. -Hal Sent from my Verizon Wireless Droid -----Original message----- From: "Carl-Philip Hänsch" <cphaensch at googlemail.com> To: Hal Finkel <hfinkel at anl.gov> Cc: llvmdev at cs.uiuc.edu Sent: Tue, Feb 14, 2012 16:10:28 GMT+00:00 Subject: Re: [LLVMdev] Vectorization: Next

On Fri, Dec 2, 2011 at 11:56 AM, Carl-Philip Hänsch <cphaensch at googlemail.com> wrote: > While trying to find a solution for this bug > http://llvm.org/bugs/show_bug.cgi?id=11235 , > I came to the conclusion that the following things can happen while > optimizing: >  - after gvn, I get new constants which are inserted into br and > add/sum/..., so there should be at least

Hi James, I fully agree with you and understand your statement about -O2. Now some questions for you: Did you try to reproduce experiments described in my previous e-mail ? Did you look at debug informations generated for 'n' parameter on x86 32-bit & x86 64-bit ? I'm working on my own front-end for LLVM and I had difficulties with debug information when they are related to x86

Hi all, I'm new to this list and I would like to know who is involved in llc ARM backend maintenance/evolution. -- Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111005/5abc7f0d/attachment.html>

On Wed, Mar 7, 2012 at 6:50 AM, Seb <babslachem at gmail.com> wrote: > Hi James, > > I fully agree with you and understand your statement about -O2. > > Now some questions for you: > Did you try to reproduce experiments described in my previous e-mail ? > Did you look at debug informations generated for 'n' parameter on x86 32-bit > & x86 64-bit ? >

That works. Thank you. Will -vectorize become default later? 2012/2/14 Hal Finkel <hfinkel at anl.gov> > If you run with -vectorize instead of -bb-vectorize it will schedule the > cleanup passes for you. > > -Hal > > *Sent from my Verizon Wireless Droid* > > > -----Original message----- > > *From: *"Carl-Philip Hänsch" <cphaensch at

2011/10/28 Chris Lattner <clattner at apple.com> > > On Oct 27, 2011, at 5:37 PM, Michael Price wrote: > > Has there been much thought of attempting to automate this process? I > could imagine a fairly standard script that scrubbed a history for > interesting tidbits. Of course a standard methodology for labeling types of > commits would help this in the future. >

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

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 =

I tested the "restricted" keyword and it works well :) The generated code is a bunch of shufflevector instructions, but after a second -O3 pass, everything looks fine. This problem is described in my ML post "passes propose passes" and occurs here again. LLVM has so much great passes, but they cannot start again when the code was somewhat simplified :( Maybe that's one

Hi James, clang is able to generate correct debug informations for 64-bit target at -O2. My feeling, given some other experiments I've done, is that debug information generated for x86 32-bit might be broken for parameters as long as they are not 'homed' in the code (local copy to an automatic variable). It seems that when llvm.declare is turned into a llvm.value for parameter there

On Mon, 2012-02-13 at 11:11 +0100, Carl-Philip Hänsch wrote: > I will test your suggestion, but I designed the test case to load the > memory directly into <4 x float> registers. So there is absolutely no > permutation and other swizzle or move operations. Maybe the heuristic > should not only count the depth but also the surrounding load/store > operations. I've attached

Hi all, Following command was working for me before: svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm Now it fails as follows: svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'http://llvm.org/svn/llvm-project/llvm/trunk ' Any idea ? Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed...

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 Devang, Not only "vtable ptr" is a problem, for this field it seems that CLANG emits a NULL metadata node which is translated into 'i32 0'. The other problem is for 'isArtificial' field with is described as being of type i1 and CLANG emits i32. Looking at sources, it seems that it should be a i32 flag field. Hope this helps, Best Regards Seb 2011/12/15 Devang

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

2011/12/9 Joerg Sonnenberger <joerg at britannica.bec.de> > On Fri, Dec 09, 2011 at 10:03:37AM +0100, Seb wrote: > > I think my explanation is not clear, my front-end did NOTt generate > > 'llvm.memcpy' it generate LL code that after use of LLVM 'opt' get > > transformed by 'loop-idom' pass into an 'llvm.memcpy' for an overlapping >