Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

"Martin v. Löwis" wrote:
> 
> Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> 
> > I'd be interested to know what the speed up is versus a different
> > mutex library (I guess glibc) and the situation on SMP.  Although I've
> > been cranky, I'd still want to do anything additional to improve RTEMS
> > situation, if still required.  Given the minimal slowdown for what I
> > consider very heav-duty threaded test cases, my recommendation is to
> > remove the i486 implementation entirely for the 3.3 release, if that
> > help linkage ABI issues...
> 
> I don't think this is desirable. AFAIK, g++ 3.3 will "mostly" maintain
> binary compatibility with g++ 3.2.
> 
> Now, with that patch accepted, there is an ABI change for i386. IMO,
> this has little impact in real life, since there are relatively few
> i386-configured 3.2 installations out there (specifically, all Linux
> distributions released with gcc 3.2 apparently have configured their
> compilers for i486+ (*)).

There may not be many i386 configured Linux distributions out there but
all embedded i386 targets are broken because i386-elf and i386-rtems
are used.

> If you would drop i486/atomicity.h, you would break binary
> compatibility with gcc-3.2-configured-for-i486+. If my understanding
> is correct (i.e. you would offer binary compatibility otherwise), I
> think i486/atomicity.h should stay.

Can we have an i386/atomicity.h which works in parallel with the
i486/atomicity?  This is essentially what (I think) was in 
the 3.2 branch except that the i386/atomicity.h is broken.

> There are also performance considerations. I have timed the i386 and
> i486 versions on my PIII (performing the same atomic increment in a
> single thread over and over again), and found that the i386 version is
> still 50% slower than the i486 version. For i386-proper, this is ok:
> you can't do better on this processor.  

Right.  And embedded i386 targets aren't going away in the foreseeable
future.  So gcc can't abandon them.

> For i486, I think the
> performance drop should be avoided, especially since more and more
> i386 systems will get replaced with i486+ over time, so many systems
> would have to pay for compatibility with systems that are rarely used.

This is why I was arguing for this code being NOT in a .h but in a 
C/C++ file which can be properly compiled for the target.  The embedded
x86 targets are probably the only ones which multilib but they do and
can actually have a proper i386 version and better i486 version in
the same installed toolset if the .h file is just a prototype.

This does beg the question of how much performance is lost with the
subroutine call.

For gcc 3.3, I would be extremely pleased if there were simply
i386 and i486 atomicity.h files so that all x86 targets work.  This
can't be said about about the 3.2 branch right now.

> Regards,
> Martin
> 
> (*) I don't know how the BSDs have configured their compilers, but I
> think cross-version compatibility doesn't matter that much since you
> won't have different distributions of, say, FreeBSD which use
> different compilers and still want to exchange binaries.

I think I understand what you are saying and agree.

--joel sherrill