apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: nonportable-atomics configure.in setting
Date Wed, 04 Dec 2013 11:02:33 GMT
I repost my comments here since they all went to the httpd list...

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
])

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?

Mime
View raw message