[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 3/4] Arm64: further speed-up to hweight{32, 64}()
On 05/06/2019 10:59, Jan Beulich wrote: On 05.06.19 at 11:24, <julien.grall@xxxxxxx> wrote:On 05/06/2019 08:42, Jan Beulich wrote:On 04.06.19 at 18:11, <julien.grall@xxxxxxx> wrote:On 5/31/19 10:53 AM, Jan Beulich wrote:According to Linux commit e75bef2a4f ("arm64: Select ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the variant using only bitwise operations on at least some hardware, and no worse on other. Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> --- RFC: To be honest I'm not fully convinced this is a win in particular in the hweight32() case, as there's no actual shift insn which gets replaced by the multiplication. Even for hweight64() the compiler could emit better code and avoid the explicit shift by 32 (which it emits at least for me).I can see multiplication instruction used in both hweight32() and hweight64() with the compiler I am using.That is for which exact implementation?A simple call hweight64().That's as ambiguous as it was before: Are you talking about un-patched code (before this series), or patches up to at least this one applied. What I'm trying to understand is if your compiler is smart enough to use MUL without us telling it to. unsigned int test_hweight64(uint64_t t) { return hweight64(t); }I looked at the difference between before and after this patch. Before the multiplication is not used. After, it was used with less instructions emitted. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |