similar to: [LLVMdev] ARM eabi calling convention

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); >

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]

See ARMCallingConv.td:113. The alignment of the arg is checked and if it's 8-byte aligned, the proper registers are chosen. deep On Tue, Aug 7, 2012 at 1:20 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > 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

On Aug 6, 2012, at 6:58 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > See ARMCallingConv.td:113. The alignment of the arg is checked and if > it's 8-byte aligned, the proper registers are chosen. Are you sure? In this case, it looks like the frontend is translating the argument type to [2 x i32], so it's not going to have 8-byte alignment. This looks like a bug to

ARM backend emits different eabi build attributes based on the ISA variant the target supports or whether certain fast-math options are passed on the command line. For example, these are the attributes that have different values depending on whether -ffast-math is passed to clang: $ clang -target armv7-linux-gnueabi -ffast-math (with -ffast-math) .eabi_attribute 20, 2 @ Tag_ABI_FP_denormal

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, although I've done S3 dispatching for more than a decade now, I think I managed to overlook/avoid the following pitfall when using NextMethod(): If you explicitly pass argument '...' to NextMethod(), you will effectively pass those argument twice to the "next" method! EXAMPLE: foo0 <- function(...) UseMethod("foo0"); foo1 <- function(...)

Hi the list I have package foo0 with a big dataset 'myData'. In DESCRIPTION, if I use 'LazyData: no', then I get: - when I open a R session : memory used=20 908 - when I attach 'library(foo0)' : memory used=24364 - then I load the set 'data(myData)' : memory used=39 668 If I use LazyData: yes', then I get - when I open a R session : memory used=20 908

Hi Duncan, What do you mean by "a data layout string in your module" ? Best Regards Seb 2011/10/18 Duncan Sands <baldrick at free.fr> > Hi Seb, > > > I'm writting following LLVM assembly: > > > > ; ModuleID = 'structaccess.ll' > > > > not having a data layout string in your module disables many optimizations. > > Ciao,

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 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 the list In the DESCRIPTION file of my package foo0, I have: Depends: foo1 Imports: foo2 Suggest: foo3 Enhence: foo4 If I understand correctly, to install foo0 on my computer, I need to already have foo1, foo2, foo3. foo4 is not necessary. I my R sesssion, when I will write: library(foo0), then the package foo1 will be attach. foo2, foo3 and foo4 will not. Is that correct? But what is

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

Hi all, I was wondering if there is a defined ABI for passing vector as parameter for ARM target. For instance is this valid to write .ll statement like: ; ModuleID = 'bugconv.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 = "thumbv7-none-linux-androideabi" define

Hi all, I'm writting following LLVM assembly: ; ModuleID = 'structaccess.ll' %struct._anon0 = type <{ i32, i32, i32 }> @s = common global %struct._anon0 zeroinitializer define arm_aapcscc void @foo() nounwind { L.entry: store i32 5, i32* getelementptr inbounds (%struct._anon0* @s, i32 0, i32 0) store i32 10, i32* getelementptr inbounds (%struct._anon0* @s, i32 0, i32 1)

Dear R developers, Taking advantage of the yesterday discussion about the use of Depends/Import/Suggests/Enhances, I would like to add a related question. Let's assume, in the DESCRIPTION file of my package foo0, I have: Depends: foo1 Imports: foo2 while in the NAMESPACE file of my package I have importFrom("foo2", f2) and within my package I use the following two external

Hi Seb, > I'm writting following LLVM assembly: > > ; ModuleID = 'structaccess.ll' > not having a data layout string in your module disables many optimizations. Ciao, Duncan. > %struct._anon0 = type <{ i32, i32, i32 }> > > @s = common global %struct._anon0 zeroinitializer > > define arm_aapcscc void @foo() nounwind { > L.entry: > store i32

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 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>*

Hi all, I was wondering if ARM aapcs calling convention defines how to pass small vectors as parameter to a routine. By small vectors, I mean with size less than a 32-bit integer. For instance if we consider following code: ; ModuleID = 'smallvect.ll' define arm_aapcscc void @foo(<2 x i8>* %p) { L.entry: %0 = load <2 x i8>* %p call arm_aapcscc void @bar(<2 x