Re: Is detecting endianness at compile-time unworkable?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The change was definitely made for performance.  Removing the if statements, conditioned upon endianess was an approx 10% improvement, which was very important to getting this library accepted into git.

Thanks,
Dan


On Mon, Jul 30, 2018 at 11:32 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:

> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> And, as an aside, the reason we can't easily make it better ourselves is
>> because the build process for git.git doesn't have a facility to run
>> code to detect this type of stuff (the configure script is always
>> optional). So we can't just run this test ourselves.
>
> It won't help those who cross-compile anyway.  I thought we declared
> "we make a reasonable effort to guess the target endianness from the
> system header by inspecting usual macros, but will not aim to cover
> every system on the planet---instead there is a knob to tweak it for
> those on exotic platforms" last time we discussed this?

Well, having said all that, I do not think I personally mind if
./configure learned to include a "compile small program and run it
to determine byte order on the build machine" as part of "we make a
reasonable effort" as long as it cleanly excludes cross building
case (and the result is made overridable just in case we misdetect
the "cross-ness" of the build).



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux