[ovs-dev] [PATCH 5/6] Re: byte-order: Make hton128() and ntoh128() behave like their counterparts.

Justin Pettit jpettit at ovn.org
Tue Nov 24 01:11:09 UTC 2015


> On Nov 23, 2015, at 5:08 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> On Mon, Nov 23, 2015 at 04:26:18PM -0800, Joe Stringer wrote:
>> On 23 November 2015 at 12:49, Joe Stringer <joestringer at nicira.com> wrote:
>>> On 23 November 2015 at 10:06, Ben Pfaff <blp at ovn.org> wrote:
>>>> When Joe added these types I assumed that he used the unconventional
>>>> prototypes for hton128() and ntoh128() because the return value
>>>> convention was inefficient.  If GCC and Clang actually optimize the use
>>>> of a return value in some kind of sensible way then I agree that the
>>>> usual convention is nicer.
>>>> 
>>>> Joe, did you have another reason?
>>> 
>>> This was mostly done based on an assumption that this was more
>>> optimal, rather than actually digging into the compiled code and
>>> seeing that it was generated differently.
>>> 
>>> Looking now, before this patch vs. after on my 64-bit system..
>>> 
>>> GCC-4.9: hton128/ntoh128 require one less MOV with this patch, but
>>> calling conventions (in format_u128) require 3 extra MOV (+4 MOV, -1
>>> LEA) for format_u128().
>>> Clang-3.7: hton128/ntoh128 are roughly equivalent, although with this
>>> patch they use some MOVUPS/MOVAPS instructions for 128-bit moves.
>>> Calling conventions seem to require as much as 6-12 (!) extra MOVs
>>> however, details below.
>> 
>> <snip>
>> 
>> Woops, looks like I missed compiler optimizations. They look much
>> closer together with --O2, so I think this patch makes sense to apply
>> without reservation.

Thanks for the thorough analysis, Joe.

> Acked-by: Ben Pfaff <blp at ovn.org>

Thanks for the reviews, Ben.  I'll push the series in a minute.

--Justin





More information about the dev mailing list