You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Daniel Lescohier <da...@cbsi.com> on 2013/12/04 01:22:42 UTC
nonportable-atomics configure.in setting
I see this in configure.in:
AC_ARG_ENABLE(nonportable-atomics,
[ --enable-nonportable-atomics Use optimized atomic code which may
produce nonportable binaries],
[if test $enableval = yes; then
force_generic_atomics=no
else
force_generic_atomics=yes
fi
],
[case $host_cpu in
i[[456]]86) force_generic_atomics=yes ;;
*) force_generic_atomics=no ;;
esac
])
I was wondering why the three host_cpus i486, i586, and i686 have special
treatment for the default setting as compared to all other cpu
architectures?
Re: nonportable-atomics configure.in setting
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 4, 2013, at 6:02 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> So it seems to have changed from "use native atomics when explicitely specified AND the cpu is compatible" to "use native atomics when explicitely specified OR the CPU is compatible but not i[456]86 " (probably to not have to declare new capable cpus as they arrive).
>
> Was this intented?
After all this time, I think using generic atomics
should *only* be done iff --enable-nonportable-atomics=no
Re: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
I repost my comments here since they all went to the httpd list...
On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier
<da...@cbsi.com>wrote:
> I see this in configure.in:
>
> AC_ARG_ENABLE(nonportable-atomics,
> [ --enable-nonportable-atomics Use optimized atomic code which may
> produce nonportable binaries],
> [if test $enableval = yes; then
> force_generic_atomics=no
> else
> force_generic_atomics=yes
> fi
> ],
> [case $host_cpu in
> i[[456]]86) force_generic_atomics=yes ;;
> *) force_generic_atomics=no ;;
> esac
> ])
>
> I was wondering why the three host_cpus i486, i586, and i686 have special
> treatment for the default setting as compared to all other cpu
> architectures?
>
>
I don't see any reason since the code in "srclib/apr/atomic/unix/ia32.c"
seems compatible with >i386 (cmpxchg starts with i486), and atomic builtins
work with gcc-v2+ (at worst USE_ATOMICS_IA32 could be defined for gcc-v1).
The issue could have been in apr_atomic_casptr() and apr_atomic_xchgptr(),
but APR_SIZEOF_VOIDP is checked to do the right thing with 32bits cpus...
The changes in configure.in last
http://svn.apache.org/viewvc?view=revision&revision=r64861, where
"force_generic_atomics" went from :
case $host in
*linux*)
apr_force_atomic_generic=1
case $host_cpu in
i486|i586|i686|powerpc64)
if test "$nonportable_atomics_enabled" = 1; then
apr_force_atomic_generic=0
fi
;;
esac
To :
AC_ARG_ENABLE(nonportable-atomics,
[ --enable-nonportable-atomics Use optimized atomic code which may
produce nonportable binaries],
[if test $enableval = yes; then
force_generic_atomics=no
else
force_generic_atomics=yes
fi
],
[case $host_cpu in
i[[456]]86) force_generic_atomics=yes ;;
*) force_generic_atomics=no ;;
esac
])
Before r64861: native atomics were enabled on i[456]86
only
when --enable-nonportable-atomics=yes.
After r64861: when --enable-nonportable-atomics is not specified, native
atomics are disabled (forcibly) on those CPUs.
So it seems to have changed from "use native atomics when explicitely
specified AND the cpu is compatible" to "use native atomics when
explicitely specified OR the CPU is compatible but not i[456]86
" (probably to not have to declare new capable cpus as they arrive).
Was this intented?
Re: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 4, 2013 at 11:11 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Dec 4, 2013 at 11:02 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
>> After r64861: native atomics are disabled (forcibly) on those CPUs,
>> whatever --enable-nonportable-atomics is.
>>
>
> Sorry, --enable-nonportable-atomics is still honored, I misread the code.
>
>
What I meant is that configure.in seem to have changed from "use native
atomics when explicitely specified AND the cpu is compatible" to "use
native atomics when explicitely specified OR the CPU is compatible but not
i[456]86", probably due to new intel capable cpus that need not be added to
list whenever they appear.
Re: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 4, 2013 at 11:02 AM, Yann Ylavic <yl...@gmail.com> wrote:
> After r64861: native atomics are disabled (forcibly) on those CPUs,
> whatever --enable-nonportable-atomics is.
>
Sorry, --enable-nonportable-atomics is still honored, I misread the code.
Re: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 4, 2013 at 10:40 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier <
> daniel.lescohier@cbsi.com> wrote:
>
>> I see this in configure.in:
>>
>> AC_ARG_ENABLE(nonportable-atomics,
>> [ --enable-nonportable-atomics Use optimized atomic code which may
>> produce nonportable binaries],
>> [if test $enableval = yes; then
>> force_generic_atomics=no
>> else
>> force_generic_atomics=yes
>> fi
>> ],
>> [case $host_cpu in
>> i[[456]]86) force_generic_atomics=yes ;;
>> *) force_generic_atomics=no ;;
>> esac
>> ])
>>
>> I was wondering why the three host_cpus i486, i586, and i686 have special
>> treatment for the default setting as compared to all other cpu
>> architectures?
>>
>>
> I don't see any reason since the code in "srclib/apr/atomic/unix/ia32.c"
> seems compatible with >i386 (cmpxchg starts with i486), and atomic builtins
> work with gcc-v2+ (at worst USE_ATOMICS_IA32 could be defined for gcc-v1).
>
> The issue could have been in apr_atomic_casptr() and apr_atomic_xchgptr(),
> but APR_SIZEOF_VOIDP is checked to do the right thing with 32bits cpus...
>
>
The changes in configure.in last
http://svn.apache.org/viewvc?view=revision&revision=r64861
, where "force_generic_atomics" went from :
case $host in
*linux*)
apr_force_atomic_generic=1
case $host_cpu in
i486|i586|i686|powerpc64)
if test "$nonportable_atomics_enabled" = 1; then
apr_force_atomic_generic=0
fi
;;
esac
To :
AC_ARG_ENABLE(nonportable-atomics,
[ --enable-nonportable-atomics Use optimized atomic code which may
produce nonportable binaries],
[if test $enableval = yes; then
force_generic_atomics=no
else
force_generic_atomics=yes
fi
],
[case $host_cpu in
i[[456]]86) force_generic_atomics=yes ;;
*) force_generic_atomics=no ;;
esac
])
So prior to r64861: native atomics were enabled on i[456]86 when
--enable-nonportable-atomics=yes.
After r64861: native atomics are disabled (forcibly) on those CPUs,
whatever --enable-nonportable-atomics is.
Was this intented?
Re: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 4, 2013 at 10:40 AM, Yann Ylavic <yl...@gmail.com> wrote:
> Sorry, I had no intention to send this offlist.
>
Well, I really strayed here, I just realize now this is the wrong list.
Sorry again Daniel and httpd folks, I'll now restate all that to the apr
list :)
Fwd: nonportable-atomics configure.in setting
Posted by Yann Ylavic <yl...@gmail.com>.
Sorry, I had no intention to send this offlist.
---------- Forwarded message ----------
From: Yann Ylavic <yl...@gmail.com>
Date: Wed, Dec 4, 2013 at 10:37 AM
Subject: Re: nonportable-atomics configure.in setting
To: Daniel Lescohier <da...@cbsi.com>
On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier
<da...@cbsi.com>wrote:
> I see this in configure.in:
>
> AC_ARG_ENABLE(nonportable-atomics,
> [ --enable-nonportable-atomics Use optimized atomic code which may
> produce nonportable binaries],
> [if test $enableval = yes; then
> force_generic_atomics=no
> else
> force_generic_atomics=yes
> fi
> ],
> [case $host_cpu in
> i[[456]]86) force_generic_atomics=yes ;;
> *) force_generic_atomics=no ;;
> esac
> ])
>
> I was wondering why the three host_cpus i486, i586, and i686 have special
> treatment for the default setting as compared to all other cpu
> architectures?
>
>
I don't see any reason since the code in "srclib/apr/atomic/unix/ia32.c"
seems compatible with >i386 (cmpxchg starts with i486), and atomic builtins
work with gcc-v2+ (at worst USE_ATOMICS_IA32 could be defined for gcc-v1).
The issue could have been in apr_atomic_casptr() and apr_atomic_xchgptr(),
but APR_SIZEOF_VOIDP is checked to do the right thing with 32bits cpus...