<div dir="ltr">Hi Joey,<div><br></div><div>   Thanks a lot for your suggestions. I improved my patch as your good advice. I wish to implement some of ACLE intrinsic based on my patch as test, but the full implementation of one ACLE intrinsic need to commit on both llvm and clang. More important thing is,  all scalar ACLE intrinsic are classified to different tables, and these tables are implemented in parallel but none of them is accomplished.  There are complex dependence among intrinsic and may be rewrite frequently.  The main purpose posting this patch at moment is to decrease overlap on such base module and make our parallel development more efficient.</div>
<div><br></div><div>Best Regards,</div><div>Kevin Qin</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/16 Joey Gouly <span dir="ltr"><<a href="mailto:joey.gouly@arm.com" target="_blank">joey.gouly@arm.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Kevin,<br>
<br>
Clang patches should be sent to cfe-commits. I cc’d them in for you.<br>
<br>
You could test this patch by including an ACLE function that you have<br>
implemented, that way we can see it works. Or if you are going to submit<br>
those soon, maybe it can go in without a test for now. Let’s see what others<br>
think about that.<br>
<br>
Just two minor points.<br>
<br>
> +static std::string Insert_BHSD_Suffix(StringRef typestr){<br>
<br>
This should just return a 'char'.<br>
<br>
> +/// Insert proper 'b' 'h' 's' 'd' behind function name if prefix 'S' is<br>
used.<br>
Can you change that to something like<br>
  Insert proper 'b', 'h', 's', 'd' suffix if 'S' prefix is used.<br>
<br>
Thanks<br>
<br>
From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a><br>
[mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a>] On Behalf Of Kevin Qin<br>
Sent: 16 August 2013 10:46<br>
To: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
Subject: [PATCH] Aarch64 Neon ACLE scalar instrinsic name mangling with BHSD<br>
suffix<br>
<div class=""><div class="h5"><br>
This patch is used to add ‘bhsd’ suffix in Neon ACLE scalar function name.<br>
1. A new type prefix ‘S’ is defined in<br>
tools/clang/include/clang/Basic/<a href="http://arm_neon.td" target="_blank">arm_neon.td</a>, which is used to mark whether<br>
enable ‘bhsd’ suffix mangle.<br>
2. If prefix ‘S’ is found before data type, proper suffix will be added<br>
according below rule:<br>
Data Type  Suffix<br>
  i8 -> b<br>
  i16 -> h<br>
  i32 f32 -> s<br>
  i64 f64 -> d<br>
 <br>
For example,<br>
If we define a new ACLE function in <a href="http://arm_neon.td" target="_blank">arm_neon.td</a> like:<br>
 <br>
def FABD : SInst<”vabd”, “sss”,  “ScSsSiSlSfSd”><br>
 <br>
Then, rebuild llvm. We would see below in<br>
INSTALL_PATH/lib/clang/3.4/include/arm_neon.h<br>
 <br>
__ai int8_t vabdb_s8(int8_t __a, int8_t __b) {<br>
  return (int8_t)__builtin_neon_vabdb_s8(__a, __b); }<br>
__ai int16_t vabdh_s16(int16_t __a, int16_t __b) {<br>
  return (int16_t)__builtin_neon_vabdh_s8(__a, __b); }<br>
…<br>
 <br>
Proper suffix is inserted in both ACLE intrinsics and builtin functions.<br>
 <br>
Because this patch only works on llvm building time, so I have no idea on<br>
writing test case for this patch. Fortunately, this patch won’t effect on<br>
any already defined ACLE functions, for its function depending on the new<br>
defined prefix ‘S’. So It is safe for current system and is developed to<br>
help implement new scalar ACLE intrinsics in parallel.<br>
 <br>
You can see each scalar ACLE function corresponds to an unique builtin<br>
function. At beginning, I planned to let series of ACLE functions with the<br>
same semantics reuse one builtin function. But this would introduce extra<br>
unnecessary convert expression in IR, for different data types have<br>
different data width. If I promote all data types to i64 and use single<br>
builtin function, then there will be only an i64 version builtin function<br>
existing in IR. Though I can add extra arg in builtin function to record the<br>
original data type, but extra data convert IR(sign extension before call and<br>
truncation after call) still exists. This will increase the difficulty in<br>
coding lower patterns in backend.<br>
 <br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div><br></div><div>Kevin Qin</div></div>
</div></div>