[RFA] Using the new atomicity builtins

Paolo Carlini pcarlini@suse.de
Thu May 26 07:50:00 GMT 2005

Benjamin Kosnik wrote:

>>Steven Bosscher suggested privately that maybe a builtin define is the
>>best solution. It looks like could boil down to something as simple as
>>(in gcc/config/i386/i386.h):
>>  if (!TARGET_386)
>>    builtin_define ("__x86_atomic__");
>>that would encompass everything i?86 and x86_64 related.
>This might be the way to go.
>A quick question: isn't configure.host's cpu_include_dir already set to
>the appropriate target based on things like -march=i486? If so,
>couldn't you just re-use this solution for the i386/i486+ issue?
Actually, the best solution appears to be:

        builtin_define ("__x86_atomic__");

which also answers your question (it took me (us) some time to figure
out the whole thing ;) : much better involving directly *architectural*
features of the target, not info related to the specific switches that
the user is passing, like -march, -mtune, and so on, which may
contradict each other, etc... In fact the TARGET_CMPXCHG macro is what
Rth is actually using inside i386.h/i386.c to decide whether the
effective target supports or not such atomic operations. You cannot make
mistakes using it. But you have to "export" it from i386.h/i386.c using
the builtin_define thing.

I'm still thinking about this, however and whether we should really push
the above compiler bits: not that are a bad idea in general, IMHO, but
maybe we can deal with the availability or not of the atomic builtin in
a cleaner way. The point is that, when the implementation of the target
bits are missing, the code generated by the compiler issues a function
call of the effective atomic builtin promitive - those have _n for the
size of the arguments at the end, in the name. In other terms after
overload resolution. *If* we could have sort-of a stub mini library that
provides bare bones implementations (basically what we are doing right
now for generic or even less, as you suggested in another context a
couple of days ago) we could use the atomic builtins everywhere, at
every time. As an improvement over the basic idea, we could
conditionalize the stubs on the target and move the current open-coded
implementations there. I hope the above is more clear.


More information about the Libstdc++ mailing list