[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