[PATCH] Aarch64 Neon ACLE scalar instrinsic name mangling with BHSD suffix

[Kevin Qin]

This patch is used to add ‘bhsd’ suffix in Neon ACLE scalar function name.

1. A new type prefix ‘S’ is defined in tools/clang/include/clang/Basic/
arm_neon.td, which is used to mark whether enable ‘bhsd’ suffix mangle.

2. If prefix ‘S’ is found before data type, proper suffix will be added
according below rule:

Data Type  Suffix

i8 -> b

i16 -> h

i32 f32 -> s

i64 f64 -> d



For example,

If we define a new ACLE function in arm_neon.td like:



def FABD : SInst<”vabd”, “sss”,  “ScSsSiSlSfSd”>



Then, rebuild llvm. We would see below in
INSTALL_PATH/lib/clang/3.4/include/arm_neon.h



__ai int8_t vabdb_s8(int8_t __a, int8_t __b) {

  return (int8_t)__builtin_neon_vabdb_s8(__a, __b); }

__ai int16_t vabdh_s16(int16_t __a, int16_t __b) {

  return (int16_t)__builtin_neon_vabdh_s8(__a, __b); }

…



Proper suffix is inserted in both ACLE intrinsics and builtin functions.



Because this patch only works on llvm building time, so I have no idea on
writing test case for this patch. Fortunately, this patch won’t effect on
any already defined ACLE functions, for its function depending on the new
defined prefix ‘S’. So It is safe for current system and is developed to
help implement new scalar ACLE intrinsics in parallel.



You can see each scalar ACLE function corresponds to an unique builtin
function. At beginning, I planned to let series of ACLE functions with the
same semantics reuse one builtin function. But this would introduce extra
unnecessary convert expression in IR, for different data types have
different data width. If I promote all data types to i64 and use single
builtin function, then there will be only an i64 version builtin function
existing in IR. Though I can add extra arg in builtin function to record
the original data type, but extra data convert IR(sign extension before
call and truncation after call) still exists. This will increase the
difficulty in coding lower patterns in backend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130816/a76b3b85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BHSD_mangling_clang_truck.patch
Type: application/octet-stream
Size: 2589 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130816/a76b3b85/attachment.obj>