Sebastien DELDON-GNB
2012-Jul-05 09:14 UTC
[LLVMdev] Vector argument passing abi for ARM ?
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 arm_aapcscc void @bugtest_CALL(i8* nocapture %.T_0375) nounwind {
L.entry:
%0 = bitcast i8* %.T_0375 to <2 x i8>*
%1 = load <2 x i8>* %0, align 2
%2 = getelementptr i8* %.T_0375, i32 2
%3 = bitcast i8* %2 to <2 x i8>*
%4 = load <2 x i8>* %3, align 2
tail call arm_aapcscc void @bugtest(<2 x i8> %1, <2 x i8> %4)
ret void
}
declare arm_aapcscc void @bugtest(<2 x i8> %c, <2 x i8> %uc)
and expect first parameter to be passed into a single 32-bit register.
using llc -mcpu=cortex-a9 -mattr=+neon
With LLVM 3.0 %c is passed into two 32-bit regs and code works.
With LLVM 3.1 it generate a misaligned load that cause a BUS error seems linked
to promote element optimization.
With LLVM trunk it generates a misaligned load that makes the assembler fail.
I guess that to avoid such problem I need to convert small vector parameters
into i32, right ?
Thanks for your answers
Best Regards
Seb
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 argument passing abi for ARM ?
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 arm_aapcscc void @bugtest_CALL(i8* nocapture %.T_0375) nounwind {
L.entry:
%0 = bitcast i8* %.T_0375 to <2 x i8>*
%1 = load <2 x i8>* %0, align 2
%2 = getelementptr i8* %.T_0375, i32 2
%3 = bitcast i8* %2 to <2 x i8>*
%4 = load <2 x i8>* %3, align 2
tail call arm_aapcscc void @bugtest(<2 x i8> %1, <2 x i8> %4)
ret void
}
declare arm_aapcscc void @bugtest(<2 x i8> %c, <2 x i8> %uc)
and expect first parameter to be passed into a single 32-bit register.
using llc -mcpu=cortex-a9 -mattr=+neon
With LLVM 3.0 %c is passed into two 32-bit regs and code works.
With LLVM 3.1 it generate a misaligned load that cause a BUS error seems linked
to promote element optimization.
With LLVM trunk it generates a misaligned load that makes the assembler fail.
I guess that to avoid such problem I need to convert small vector parameters
into i32, right ?
Thanks for your answers
Best Regards
Seb
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Sebastien DELDON-GNB
2012-Jul-05 09:27 UTC
[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 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 argument passing abi for ARM ? > > 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 arm_aapcscc void @bugtest_CALL(i8* nocapture %.T_0375) nounwind > { > L.entry: > %0 = bitcast i8* %.T_0375 to <2 x i8>* > %1 = load <2 x i8>* %0, align 2 > %2 = getelementptr i8* %.T_0375, i32 2 > %3 = bitcast i8* %2 to <2 x i8>* > %4 = load <2 x i8>* %3, align 2 > tail call arm_aapcscc void @bugtest(<2 x i8> %1, <2 x i8> %4) > ret void > } > > declare arm_aapcscc void @bugtest(<2 x i8> %c, <2 x i8> %uc) > > and expect first parameter to be passed into a single 32-bit register. > using llc -mcpu=cortex-a9 -mattr=+neon > With LLVM 3.0 %c is passed into two 32-bit regs and code works. > With LLVM 3.1 it generate a misaligned load that cause a BUS error > seems linked to promote element optimization. > With LLVM trunk it generates a misaligned load that makes the assembler > fail. > I guess that to avoid such problem I need to convert small vector > parameters into i32, right ? > > Thanks for your answers > Best Regards > Seb > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies.