linaro-toolchain

linaro-toolchain@lists.linaro.org

2 participants
5792 discussions

[PATCH] libhadoop: CRC: ARM NEON support.

by Steve Capper

Hello linaro-toolchain, This is a patch to add a NEON optimised buffer folding routine to Hadoop 2.0.2-alpha. It allows for faster CRC32c checksum computation. The code is in the form of NEON intrinsics, and details of the implementation can be found at: https://wiki.linaro.org/LEG/Engineering/CRC This patch is against Hadoop 2.0.2-alpha: https://github.com/apache/hadoop-common/tree/branch-2.0.2-alpha I've sent this to linaro-toolchain because I would like the NEON intrinsic implementation to be scrutinised. I would be particularly interested in any superfluous instructions being identified or any bad practices that could be cleaned up before opening these patches up more. Any comments/critique would really be appreciated. Thanks, -- Steve Signed-off-by: Steve Capper <steve.capper(a)linaro.org> --- .../hadoop-common/src/JNIFlags.cmake | 2 + .../native/src/org/apache/hadoop/util/bulk_crc32.c | 142 +++++++++++++++++++- 2 files changed, 142 insertions(+), 2 deletions(-) diff --git a/hadoop-common-project/hadoop-common/src/JNIFlags.cmake b/hadoop-common-project/hadoop-common/src/JNIFlags.cmake index aba4c18..5c9336a 100644 --- a/hadoop-common-project/hadoop-common/src/JNIFlags.cmake +++ b/hadoop-common-project/hadoop-common/src/JNIFlags.cmake @@ -36,6 +36,8 @@ endif (JVM_ARCH_DATA_MODEL EQUAL 32) # Determine float ABI of JVM on ARM Linux if (CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" AND CMAKE_SYSTEM_NAME STREQUAL "Linux") + message("Enabling NEON support.") + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mfpu=neon") find_program(READELF readelf) if (READELF MATCHES "NOTFOUND") message(WARNING "readelf not found; JVM float ABI detection disabled") diff --git a/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/util/bulk_crc32.c b/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/util/bulk_crc32.c index 8822b5c..6282c60 100644 --- a/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/util/bulk_crc32.c +++ b/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/util/bulk_crc32.c @@ -41,6 +41,16 @@ static inline uint32_t crc_val(uint32_t crc); static uint32_t crc32_zlib_sb8(uint32_t crc, const uint8_t *buf, size_t length); uint32_t crc32c_sb8(uint32_t crc, const uint8_t *buf, size_t length); +#ifdef __ARM_NEON__ +#include <arm_neon.h> +static uint32_t crc32c_neon(uint32_t crc, const uint8_t *buf, size_t length); +#undef USE_PIPELINED +#define CRC32C_FUNC crc32c_neon +#else +#define CRC32C_FUNC crc32c_sb8 +#endif /* __ARM_NEON__ */ + + #ifdef USE_PIPELINED static void pipelined_crc32c(uint32_t *crc1, uint32_t *crc2, uint32_t *crc3, const uint8_t *p_buf, size_t block_size, int num_blocks); #endif @@ -58,7 +68,7 @@ int bulk_calculate_crc(const uint8_t *data, size_t data_len, crc_update_func = crc32_zlib_sb8; break; case CRC32C_POLYNOMIAL: - crc_update_func = crc32c_sb8; + crc_update_func = CRC32C_FUNC; break; default: return -EINVAL; @@ -100,7 +110,7 @@ int bulk_verify_crc(const uint8_t *data, size_t data_len, do_pipelined = 1; #endif } else { - crc_update_func = crc32c_sb8; + crc_update_func = CRC32C_FUNC; } break; default: @@ -256,6 +266,134 @@ static uint32_t crc32_zlib_sb8( return crc; } +#ifdef __ARM_NEON__ + +/* + * Functions to reduce the size of the input buffer (fold) on ARM + * NEON. The smaller buffer has the same CRC32c checksum as the + * original. + * + * Most of the NEON buffer folding work takes place in the function + * below. We do the following: + * 1) 4 sets of vmull.p8's + * 2) Combine these to give a "vmull.p32" (lf3) + * 3) Shift left 1 bit to account for the endianess of multiplication. + * + * The folding and multiplication logic can be found documented at: + * https://wiki.linaro.org/LEG/Engineering/CRC + */ +static inline uint64x1_t crc32c_neon_proc_part(poly8x8_t lhs, poly8x8_t rhs1, + poly8x8_t rhs2, poly8x8_t rhs3, poly8x8_t rhs4) +{ + poly16x8_t lm1, lm2, lm3, lm4; + poly16x4x2_t lz1, lz2; + uint16x4_t le1, le2; + uint32x2_t le3; + uint32x4_t ls1, ls2, lf1, lf2; + uint64x2_t ls3, le4; + uint64x1_t lf3, lf4; + + lm1 = vmull_p8(lhs, rhs1); + lm2 = vmull_p8(lhs, rhs2); + lz1 = vuzp_p16(vget_low_p16(lm2), vget_high_p16(lm2)); + le1 = veor_u16(vreinterpret_u16_p16(lz1.val[0]), + vreinterpret_u16_p16(lz1.val[1])); + ls1 = vshll_n_u16(le1, 8); + lf1 = veorq_u32(ls1, vreinterpretq_u32_p16(lm1)); + + lm3 = vmull_p8(lhs, rhs3); + lm4 = vmull_p8(lhs, rhs4); + lz2 = vuzp_p16(vget_low_p16(lm4), vget_high_p16(lm4)); + le2 = veor_u16(vreinterpret_u16_p16(lz2.val[0]), + vreinterpret_u16_p16(lz2.val[1])); + ls2 = vshll_n_u16(le2, 8); + lf2 = veorq_u32(ls2, vreinterpretq_u32_p16(lm3)); + + le3 = veor_u32(vget_low_u32(lf2), vget_high_u32(lf2)); + ls3 = vshll_n_u32(le3, 16); + le4 = veorq_u64(ls3, vreinterpretq_u64_u32(lf1)); + lf3 = vreinterpret_u64_u32(veor_u32(vget_low_u32(vreinterpretq_u32_u64(le4)), + vget_high_u32(vreinterpretq_u32_u64(le4)))); + lf4 = vshl_n_u64(lf3, 1); + return lf4; +} + +static uint32_t crc32c_neon(uint32_t crc, const uint8_t *buf, size_t length) { + poly8x8_t xor_constant, lhs1, lhs2, lhs3, lhs4, rhs1, rhs2, rhs3, rhs4; + poly8x16_t lhl1, lhl2; + + uint64_t residues[4]; + uint32_t loop; + + if (length % 32) + return crc32c_sb8(crc, buf, length); + + /* + * because crc32c has an initial crc value of 0xffffffff, we need to + * pre-fold the buffer before folding begins proper. + * The following constant is computed by: + * 1) finding a 8x32 bit value that gives a 0xffffffff crc (with initial value 0) + * (this will be 7x32 bit 0s and 1x32 bit constant) + * 2) run a buffer fold (with 0 xor_constant) on this 8x32 bit value to get the + * xor_constant. + */ + xor_constant = vcreate_p8(0x3E43E474A2870290); + + if (crc != 0xffffffff) + return crc32c_sb8(crc, buf, length); + + /* k1 = x^288 mod P(x) - bit reversed */ + /* k2 = x^256 mod P(x) - bit reversed */ + + rhs1 = vcreate_p8(0x510AC59A9C25531D); /* k2:k1 */ + rhs2 = vcreate_p8(0x0A519AC5259C1D53); /* byte swap */ + rhs3 = vcreate_p8(0xC59A510A531D9C25); /* half word swap */ + rhs4 = vcreate_p8(0x9AC50A511D53259C); /* byte swap of half word swap */ + + lhl1 = vld1q_p8((const poly8_t *) buf); + lhl2 = vld1q_p8((const poly8_t *) buf + 16); + + lhs1 = vget_low_p8(lhl1); + lhs2 = vget_high_p8(lhl1); + lhs3 = vget_low_p8(lhl2); + lhs4 = vget_high_p8(lhl2); + + /* pre-fold lhs4 */ + lhs4 = vreinterpret_p8_u16(veor_u16(vreinterpret_u16_p8(lhs4), + vreinterpret_u16_p8(xor_constant))); + + for(loop = 0; loop < (length - 32)/32; ++loop) { + uint64x1_t l1f4, l2f4, l3f4, l4f4; + + l1f4 = crc32c_neon_proc_part(lhs1, rhs1, rhs2, rhs3, rhs4); + l2f4 = crc32c_neon_proc_part(lhs2, rhs1, rhs2, rhs3, rhs4); + l3f4 = crc32c_neon_proc_part(lhs3, rhs1, rhs2, rhs3, rhs4); + l4f4 = crc32c_neon_proc_part(lhs4, rhs1, rhs2, rhs3, rhs4); + + lhl1 = vld1q_p8((const poly8_t *) (buf + 32 * (loop + 1))); + lhl2 = vld1q_p8((const poly8_t *) (buf + 32 * (loop + 1) + 16)); + + __builtin_prefetch(buf + 32 * (loop + 2)); + + lhs1 = vget_low_p8(lhl1); + lhs2 = vget_high_p8(lhl1); + lhs3 = vget_low_p8(lhl2); + lhs4 = vget_high_p8(lhl2); + + lhs1 = vreinterpret_p8_u64(veor_u64(vreinterpret_u64_p8(lhs1), l1f4)); + lhs2 = vreinterpret_p8_u64(veor_u64(vreinterpret_u64_p8(lhs2), l2f4)); + lhs3 = vreinterpret_p8_u64(veor_u64(vreinterpret_u64_p8(lhs3), l3f4)); + lhs4 = vreinterpret_p8_u64(veor_u64(vreinterpret_u64_p8(lhs4), l4f4)); + } + + vst1q_p8((poly8_t *) &residues[0], vcombine_p8(lhs1, lhs2)); + vst1q_p8((poly8_t *) &residues[2], vcombine_p8(lhs3, lhs4)); + + return crc32c_sb8(0, (const uint8_t *)residues, 32); +} + +#endif /*__ARM_NEON__ */ + /////////////////////////////////////////////////////////////////////////// // Begin code for SSE4.2 specific hardware support of CRC32C /////////////////////////////////////////////////////////////////////////// -- 1.7.9.5

13 years, 5 months

[ACTIVITY] 1 - 5 April 2013

by Omair Javaid

== Progress == * Investigated gdb test cases that are failing on arm-remote gdbserver configuration. -- Fixed some failures by updating host cross compiler version -- Fixed some failures by fixing environment issue where not being loaded properly. -- All test cases that need to build a shared library and transfer it to remote target FAIL due to problems which seems like dejaganu limitations. * Ran GDB test suite on x86_64 remote gdbserver configuration and compared performance of same configuration on arm. * Got most documentation ready for Ireland Visa application, still waiting on invitation letter and hotel booking details. *** Still No blue-print available to log work in JIRA. == Plan == * Investigate compiler version specific and general failures on arm remote gdbserver configuration. * Start on investigation/fixing of arm specific failures in gdb test suite results. * Submit Ireland visa application after receiving invitation letter and hotel booking details. * Planned Holiday -- Planned Day off on Friday 12th April 2013 for car checkup in workshop.

13 years, 5 months

[ACTIVITY] 2 - 5 Apr 2013

by Kugan

== Summary == - benchmarking coremark with VRP based extension elimination * extension elimination in some cases affecting other optimizations * With this improvements are marginal (details below) == Plan == - study crc where extension elimination is resulting in bad code - Find a solution ==Details== If an assignment gimple statement has RHS expression value that can fit in LHS type, truncation is redundant. Zero/sign extensions are redundant in this case and rtl statement can be replaced as from: (insn 12 11 0 (set (reg:SI 110 [ D.4128 ]) (zero_extend:SI (subreg:HI (reg:SI 117) 0))) c5.c:8 -1 (nil)) to: (insn 12 11 0 (set (subreg/s/u:HI (reg:SI 110 [ D.4128 ]) 0) (subreg:HI (reg:SI 117) 0)) c5.c:8 -1 (nil)) With this change, for the following case: short unPack( unsigned char c ) { /* Only want lower four bit nibble */ c = c & (unsigned char)0x0F ; if( c > 7 ) { /* Negative nibble */ return( ( short )( c - 16 ) ) ; } else { /* positive nibble */ return( ( short )c ) ; } } asm without elimination unPack: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. and r0, r0, #15 cmp r0, #7 subhi r0, r0, #16 uxthhi r0, r0 sxth r0, r0 bx lr .size asm with elimination unPack: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. and r0, r0, #15 cmp r0, #7 subhi r0, r0, #16 sxth r0, r0 bx lr In some cases, changed rtl statement is not eliminated by later passes and is generated as a mov instruction. Worse, it also seems to affect the other optimization passes and resulting in worse code for crc. Not found the cause for it yet.

13 years, 5 months

[ACTIVITY] 1 - 5 Apr 2013

by Venkataramanan Kumar

== Progress == * gc sections tests Completed adding gc-section test cases. 1. TLS and GOT tests. http://sourceware.org/ml/binutils/2013-03/msg00273.html 2. PLT tests. http://sourceware.org/ml/binutils/2013-03/msg00273.html * Evaluate gprof work. There is one function hook "find_call" which is machine dependent and is written for i386.c/sparc Then there are changes in configure.in to add architecture details. * 1-1 with Matt. == Plan == Continue gprof support work for Aarch64

13 years, 5 months

[ACTIVITY] Week 14

by Renato Golin

== Progress == * Buildbots - All ARM build-bots GREEN! Hurray!!! :D - Improving sort comparison functions makes output reproducible on all machines - Fixed fpcmp, which fixes sqlite3 report - A bad commit broke lots of tests, reverted - Adding a self-hosting check-all Pandaboard - In theory, it works, but config is not perfect yet * Arndale - Suse image is not stable enough, installed Linaro (325) - Fathi got GCC bootstrapping with it, should work - Installed a heat-sink on the board, should reduce problems - Still got network issues, may be the mac address - Someone could liaise with Dave Pigott to get a new MAC on the DHCP * EuroLLVM 2013 - Badges, finishing touches == Plan == * Holidays next week, then * Check with Galina about Beagle bots * Finish Panda self-host + test-suite A9 bot * Gather info and hardware for 3.3 release tests * Plan for the future!

13 years, 5 months

[ACTIVITY] Week 14

by Will Newton

== Progress == * Short week (2 days) * Tested memcpy on big endian. * Updated newlib memcpy patch. * More digging into glibc IFUNC. == Issues == * None. == Plan == * Try and get newlib mempcy patch accepted. * IFUNC... -- Will Newton Toolchain Working Group, Linaro

13 years, 5 months

[ACTIVITY] Week 14

by Yvan Roux

== Issues == * None == Progress == * Boehm-gc AArch64 support backport in GCC: - Ping maintainers, no response yet. * Libunwind AArch64 support: - No significant improvements, task preempted by review roster. * Merge request review roster: - Lots of reviews done and ongoing to prepare 4.6, 4.7 en 4.8 releases. == Plan == * Libunwind AArch64 support: - Fix and submit upstream.

13 years, 5 months

[ACTIVITY] 2-5 April 2013

by Christophe Lyon

== Progress == * Disable-peeling: - Still waiting for the results from cbuild. Because of many merges (pre-release week), there are a lot of jobs in the queue :-( * Libsanitizer: - tried to understand why isatty(2) returns true when executing the testsuite via qemu. * Neon intrinsics codegen: - benchmarking in bare-machine shows that GCC is actually ~5% faster than RVCT on this sample codec. - to be further discussed internally * Neon intrinsics testsuite: - looking at FP16 support. * Turnoff 64bits ops in Neon: - backport in 4.8 done by Matt during the release merges. * Arndale: a few attempts to use it, but it's still unstable. * Internal support == Next == * Disable-peeling: Analyze bench results when available. * Revert-coalesce-vars: Analyze bench results when available. * Libsanitizer: contine isatty(2) study wrt qemu/expect. * Neon intrinsics: check internally for other codecs

13 years, 5 months

[ACTIVITY] report week 14

by Peter Maydell

[short week, two days] Progress: * qemu maintenance ** arm-devs pull request (and associated code review, etc) * VIRT-4 [Guest migration support for KVM] ** VIRT-49: implement cp15 sync with kernel *** some forward motion, but partway through realised some work I thought had been committed last year hadn't been, so: ** VIRT-73 *** new work item, covering updating the migration state for the CPU itself to use VMState structures, by updating, testing and tweaking some patches from Juan Quintela from last year *** have done the 'update' part; tests and tweaks still todo -- PMM

13 years, 5 months

[ACTIVITY] Week 14

by Zhenqiang Chen

Summary: * Investigate conditional compare. Details: 1. Expand conditional compare as TRUTH_AND_EXPR/TRUTH_IOR_EXPR for tests. 2. Test tree-level changes for conditional compare. * Fix/workaround most ICE issues in regression tests. * Still some fails which expected VRP can optimize the cases. 3. Try to build Coremark and find that conditional compare does block optimizations, which leads to worse performance. Plan: * Investigate VRP and other optimizations to handle conditional compare. * Raise the propose for upstream discussion. Planned leaves: * April 4-8: Chinese Ching Ming Festival and annual leaves. * April 12: Internal team event. * April 16-17: Internal training. Best Regards! -Zhenqiang

13 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain