aboutsummaryrefslogtreecommitdiffstats
path: root/libdl
diff options
context:
space:
mode:
authorElliott Hughes <enh@google.com>2019-09-27 14:42:39 -0700
committerMichael Bestas <mkbestas@lineageos.org>2019-12-11 19:06:53 +0200
commitedb3c4489ee8f2f0cf1fbca5f7111086f7318aac (patch)
tree0b0d3b1e9a0dbc4ab5093286589275d2fc74c791 /libdl
parentf21a5b97f8d849c074f82ee7f7ea70ab2285d8bc (diff)
downloadandroid_bionic-staging/lineage-17.0_merge-android-10.0.0_r9.tar.gz
android_bionic-staging/lineage-17.0_merge-android-10.0.0_r9.tar.bz2
android_bionic-staging/lineage-17.0_merge-android-10.0.0_r9.zip
Optimize tolower(3)/toupper(3) from <ctype.h>.staging/lineage-17.0_merge-android-10.0.0_r9
The tables in the BSD tolower/toupper are slower for ASCII than just doing the bit twiddling. We can't actually remove the tables on LP32, so move them into the "cruft" we keep around for backwards compatibility (but remove them for LP64 where they were never exposed). I noticed that the new bit-twiddling tolower(3) was performing better on arm64 than toupper(3). The 0xdf constant was requiring an extra MOV, and there isn't a BIC that takes an immediate value. Since we've already done the comparison to check that we're in the right range (where the bit is always set), though, we can EOR 0x20 to get the same result as the missing BIC 0x20 in just one instruction. I've applied that same optimization to towupper(3) too. Before: BM_ctype_tolower_n 3.30 ns 3.30 ns 212353035 BM_ctype_tolower_y 3.31 ns 3.30 ns 211234204 BM_ctype_toupper_n 3.30 ns 3.29 ns 214161246 BM_ctype_toupper_y 3.29 ns 3.28 ns 207643473 BM_wctype_towupper_ascii_n 3.53 ns 3.53 ns 195944444 BM_wctype_towupper_ascii_y 3.48 ns 3.48 ns 199233248 After: BM_ctype_tolower_n 2.93 ns 2.92 ns 242373703 BM_ctype_tolower_y 2.88 ns 2.87 ns 245365309 BM_ctype_toupper_n 2.93 ns 2.93 ns 243049353 BM_ctype_toupper_y 2.89 ns 2.89 ns 245072521 BM_wctype_towupper_ascii_n 3.34 ns 3.33 ns 212951912 BM_wctype_towupper_ascii_y 3.29 ns 3.29 ns 214651254 (Why do both the "y" and "n" variants speed up with the EOR change? Because the compiler transforms the code so that we unconditionally do the bit twiddling and then use CSEL to decide whether or not to actually use the result.) We also save 1028 bytes of data in the LP64 libc.so. Test: ran the bionic benchmarks and tests Change-Id: I7829339f8cb89a58efe539c2a01c51807413aa2d
Diffstat (limited to 'libdl')
0 files changed, 0 insertions, 0 deletions