Hi Ana, Sorry for that mistake. I merged and tested my patch on our daily updated internal repo. So it may have latency with truck and just missed Hao's patch at the time I merged my patch. Here is the patch rebased on truck now. Please try again. Thanks.
2013/8/21 Ana Pazos <[email protected]> > Hi Kevin,**** > > ** ** > > I am trying your patch now.**** > > The first thing I noticed is that the patch does not merge cleanly.**** > > It seems you do not have Hao’s previous clang commit ( > http://llvm.org/viewvc/llvm-project?view=revision&revision=188452 -Clang > and AArch64 backend patches to support shll/shl and vmovl instructions and > ACLE function).**** > > Can you rebase and repost your patch?**** > > ** ** > > Thanks,**** > > Ana.**** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Kevin Qin > *Sent:* Monday, August 19, 2013 2:43 AM > *To:* Joey Gouly > *Cc:* [email protected]; [email protected] > *Subject:* Re: [PATCH] Aarch64 Neon ACLE scalar instrinsic name mangling > with BHSD suffix**** > > ** ** > > Hi Joey,**** > > ** ** > > 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.**** > > ** ** > > Best Regards,**** > > Kevin Qin**** > > ** ** > > 2013/8/16 Joey Gouly <[email protected]>**** > > Hi Kevin, > > Clang patches should be sent to cfe-commits. I cc’d them in for you. > > You could test this patch by including an ACLE function that you have > implemented, that way we can see it works. Or if you are going to submit > those soon, maybe it can go in without a test for now. Let’s see what > others > think about that. > > Just two minor points. > > > +static std::string Insert_BHSD_Suffix(StringRef typestr){ > > This should just return a 'char'. > > > +/// Insert proper 'b' 'h' 's' 'd' behind function name if prefix 'S' is > used. > Can you change that to something like > Insert proper 'b', 'h', 's', 'd' suffix if 'S' prefix is used. > > Thanks > > From: [email protected] > [mailto:[email protected]] On Behalf Of Kevin Qin > Sent: 16 August 2013 10:46 > To: [email protected] > Subject: [PATCH] Aarch64 Neon ACLE scalar instrinsic name mangling with > BHSD > suffix**** > > > 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. > > > > **** > > > > **** > > ** ** > > -- **** > > Best Regards,**** > > ** ** > > Kevin Qin**** > -- Best Regards, Kevin Qin
BHSD_mangling_clang_truck3.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
