Re: [PATCH] cmake: Default to PNG_ARM_NEON=off for arm targets

--===============7420933745798807716==
Content-Type: multipart/alternative; boundary="000000000000d7e4db05eb05b3cd"

--000000000000d7e4db05eb05b3cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 14, 2022 at 1:59 PM Martin Storsj=C3=B6 <[email protected]> wrot=
e:

> On Fri, 14 Oct 2022, John Bowler wrote:
>
> FWIW, aarch64 doesn't have 64 bit instructions, the instructions are stil=
l
> 32 bit each.


Ah, right; I'm not up-to-date with the aarch64 stuff.  It would make some
sense that switching is not possible.  The main justification for thumb was
that it fixed the sparsity of the 32-bit instruction space; the encoding of
a condition code in 4 bits of every instruction was a real help in avoiding
the need for branch prediction but meant that only one sixteenth of the
code space was regularly used.

I just tried and there is no support that I can see for thumb in aarch64
either.  For sure GCC compiler won't accept -mthumb and  /proc/cpuinfo
doesn't either "thumb" or, for that matter, "neon" (so the
PNG_ARM_NEON_CHECK will fail; yet another reason why it should be
removed...)

thumb and
> arm can easily be intermixed in the same binary/process, indeed via
> trampolines (and even without that, with the instruction mode being
> encoded in the lowest bit of code addresses).
>

I tried to test that too on armv7l, where thumb and neon are both present
in cpuinfo.  Unfortunately I have a Raspbian build and the make step
immediately fails with "sorry, unimplemented" coming from atoi in
stdlib.h...  I did test with -mfpu=3Dvfpv4 because I thought that stopped
NEON working, but it still built the filter_neon_intrinsics code (along
with palette_neon_intrinsics) and "make check" seems to be passing.

Sadly there are too many combinations to test and, worse, people who have
some system that can handle the optimizations but doesn't pass the myriad
of compiler #define checks probably just hard enable via one of the
configuration options and do not send a patch to the tests.

--000000000000d7e4db05eb05b3cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Oct 14, 2022 at 1:59 PM Martin St=
orsj=C3=B6 &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;=
 wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On Fri, 14 Oct 2022, John Bowler wrote:<br>
<br>FWIW, aarch64 doesn&#39;t have 64 bit instructions, the instructions ar=
e still <br>
32 bit each. </blockquote><div><br></div><div>Ah, right; I&#39;m not up-to-=
date with the aarch64 stuff.=C2=A0 It would make some sense that switching =
is not possible.=C2=A0 The main justification for thumb was that it fixed t=
he sparsity of the 32-bit instruction space; the encoding of a condition co=
de in 4 bits of every instruction was a real help in avoiding the need for =
branch prediction but meant that only one sixteenth of the code space was r=
egularly used.</div><div><br></div><div>I just tried and there is no suppor=
t that I can see for thumb in aarch64 either.=C2=A0 For sure GCC compiler w=
on&#39;t accept -mthumb and=C2=A0 /proc/cpuinfo doesn&#39;t either &quot;th=
umb&quot; or, for that matter, &quot;neon&quot; (so the PNG_ARM_NEON_CHECK =
will fail; yet another reason why it should be removed...)</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">thumb and <br>
arm can easily be intermixed in the same binary/process, indeed via <br>
trampolines (and even without that, with the instruction mode being <br>
encoded in the lowest bit of code addresses).<br></blockquote><div><br></di=
v><div>I tried to test that too on armv7l, where thumb and neon are both pr=
esent in cpuinfo.=C2=A0 Unfortunately I have a Raspbian build and the make =
step immediately fails with &quot;sorry, unimplemented&quot; coming from at=
oi in stdlib.h...=C2=A0 I did test with -mfpu=3Dvfpv4 because I thought tha=
t stopped NEON working, but it still built the filter_neon_intrinsics code =
(along with palette_neon_intrinsics) and &quot;make check&quot; seems to be=
 passing.</div><div><br></div><div>Sadly there are too many combinations to=
 test and, worse, people who have some system that can handle the optimizat=
ions but doesn&#39;t pass the myriad of compiler #define checks probably ju=
st hard enable via one of the configuration options and do not send a patch=
 to the tests.</div></div></div>

--000000000000d7e4db05eb05b3cd--


--===============7420933745798807716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7420933745798807716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

--===============7420933745798807716==--