similar to: [LLVMdev] Vector argument passing abi for ARM ?

Hi Rotem, Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? Best Regards Seb > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Thursday, July 05, 2012 11:21 AM > To: Sebastien DELDON-GNB; llvmdev at cs.uiuc.edu > Subject: RE: Vector argument passing abi for ARM ? > > The

The argument passing calling convention is undefined for illegal types, such as <2 x i8>. The invalid misaligned loads on ARM sounds like a bug in the ARM backend. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sebastien DELDON-GNB Sent: Thursday, July 05, 2012 12:14 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Vector

Hi Duncan, I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. Here is a small example to reproduce the problem I'm experiencing: ; ModuleID = 'bugparam.ll' target datalayout =

Hi Sebastien, > Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? the code generators are supposed to produce working code no matter what the parameter type is. The fact that the ARM ABI doesn't specify how <2 x i8> is passed just means that the code generators can pass it using whatever technique it feels like (since it

Hi Sebastien, > I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. yes it is a bug. > I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. I didn't read Nadav's reply as saying there was no bug, in fact he explicitly said in his email

Hi all, considering following .ll file ; ModuleID = 'vect3x.ll' target triple = "armv7-none-linux-gnueabi" define arm_aapcscc void @test_hi_char8(i8* %.T0351, <8 x i8>* nocapture %srcA, <4 x i8>* nocapture %dst) noinline { L.entry: %0 = tail call arm_aapcscc i32 (...)* @get_global_id(i8* %.T0351, i32 0) %1 = bitcast <8 x i8>* %srcA to <4 x i8>*

Sounds like a bug in vector promote. If I restore this flag and use -promote-elements=0 everything works for me. Please fill a PR in LLVM bugzilla and assign to Nadav. On Mon, Jun 25, 2012 at 5:04 PM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > > considering following .ll file > > ; ModuleID = 'vect3x.ll' > target triple =

Understood for the aligned case, I want to measure performance degradation for unaligned case. I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction it will raise an exception (SEGFAULT), I just want to know if there

On Feb 28, 2011, at 2:58 AM, Sebastien DELDON-GNB wrote: > Understood for the aligned case, I want to measure performance degradation for unaligned case. > I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction

Hi all, Is there a way to force llc to generate movupd instruction instead of movapd for x86 target ? I know that movapd is more performant, but I would like to measure degradation when alignment constraints are not met. Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Anton & Nadav, I filled this problem a while ago here http://llvm.org/bugs/show_bug.cgi?id=13111 Thinking it first was an LLVM opt bug. Shall I assign it to Nadav or create a new one ? Seb ________________________________________ De : Anton Korobeynikov [anton at korobeynikov.info] Date d'envoi : lundi 25 juin 2012 15:31 À : Sebastien DELDON-GNB Cc : LLVMdev at cs.uiuc.edu; Rotem,

Sebastien DELDON-GNB <sebastien.deldon at st.com> writes: > Hi all, > > Is there a way to force llc to generate movupd instruction instead of movapd for x86 target ? > > I know that movapd is more performant, but I would like to measure degradation when alignment constraints are not met. On modern processors a movupd on aligned data is going to be indistinguishable in

Hi Eli, Thanks for the answer, it clarifies the situation for me. Do you know if there is Pass in LLVM that could be adapted to 'legalize' intrinsics calls ? Or shall I define my own intrinsics for non supported types ? Best Regards Seb ________________________________________ De : Eli Friedman [eli.friedman at gmail.com] Date d'envoi : vendredi 21 septembre 2012 11:54 À : Sebastien

Hi all, I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: ; ModuleID = 'vmax.ll' target datalayout = "e-p:32:32:32-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-n32" target triple =

On Sep 21, 2012, at 2:58 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi Eli, > > Thanks for the answer, it clarifies the situation for me. Do you know if there is Pass in LLVM that could be adapted to 'legalize' intrinsics calls ? > Or shall I define my own intrinsics for non supported types ? You should never generate these sorts of intrinsics with

On Fri, Sep 21, 2012 at 1:28 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. > Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: > > > ; ModuleID = 'vmax.ll' > target datalayout =

When I compile this program *$ cat vararg1-main.c typedef struct { double d; } S0; S0 g1; void foo0(int a, ...); int main(int argc, char **argv) { S0 s0 = { 2.0 }; foo0(1, s0); printf("%f\n", g1.d); * * return 0; }* with this command, *$ clang -target arm-none-linux-gnueabi-gcc -ccc-clang-archs armv7 -emit-llvm vararg1-main.c -S -o vararg1-main.ll -O3* I get this

Yes, I see the load is 8-byte aligned in the bit code. My question was, assuming that arguments requiring double word alignment have to be passed in even/odd registers, how does the backend know that %0 has to be passed in register r2 and r3? *tail call arm_aapcscc void (i32, ...)* @foo0(i32 1, [2 x i32] %0) nounwindt * It doesn't seem that ARM backend can figure out that "[2 x i32]

On Aug 6, 2012, at 3:21 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > When I compile this program > > $ cat vararg1-main.c > > typedef struct { > double d; > } S0; > > S0 g1; > > void foo0(int a, ...); > > int main(int argc, char **argv) { > S0 s0 = { 2.0 }; > > foo0(1, s0); > > printf("%f\n", g1.d); >

Hello Renato, You're pointing me at ARM intrinsics related to loads, problem that I've reported in original e-mail, is not support for vector loads, but support for 'vmaxs'. For instance, there is no vector loads of 16 floats in ARM ISA but it is legal to write in LLVM: ; ModuleID = 'vadd.ll' target datalayout =