Fwd: nonportable-atomics configure.in setting

[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...

Re: nonportable-atomics configure.in setting

[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

[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

[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

[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 :)