On 11/21/2013 06:05 AM, Hans-Peter Nilsson wrote:
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
Support for atomic types having bigger alignment than the
corresponding non-atomic types is limited: it includes the code to
increase the alignment of types whose size is exactly 1, 2, 4, 8 or 16
to that of the corresponding integer type [*], but not anything for
target-specific alignment increases.
Target-maintainer perspective here: do I read that correctly,
that by default adding _Atomic raises the alignment of that type
to the "natural" one, for all targets?
To wit,
It sets up the default alignment for all atomic integral types to be
that of the natural alignment of their integer counterpart. ie
alignof(_Atomic short) = alignof (short)
For non-integral types, if sizeof (type) == sizeof (integral-type),
then it makes sure that alignof (type) is at least as large as alignof
(_Atomic integral-type), and overrides it if necessary, allowing the
lock-free routines to work the same for non-integral types.
There's code for target-specific
alignment on the branch (and I intend to merge trunk back to the
branch once this patch is on trunk, so it's easy to tell what the
changes still left on the branch are), should any target maintainers
wish to have such alignment.
...is that part needed for alignment that is only
target-specific and other-than-natural? For example, 8-byte
aligment where required for atomic 4-byte types?
Yes, I believe the override code is still on the branch. There is a
target hook which allows the alignment for an atomic type to be changed.
So, the cris port would be able to override the alignment of the
atomicHI_type_node and make it 4 bytes aligned, which would then cause
any variable declared as _Atomic short to automatically be 4 byte aligned.
Or is that part also required for
anything-other-than-ordinary-C-type alignment for the target;
say, natural 4-byte alignment of 4-byte-types for targets where
alignment is otherwise "packed"; where only 1-byte alignment of
the basic type is ABI-mandated?
If I understand correctly, yes, it would be needed there as well.... if
the compiler thinks alignof (int) is 1, then I believe it will set
alignof(_Atomic int) to 1 as well, and that's probably not good.
Basically, atomic_types are given their own type nodes in tree.c:
atomicQI_type_node = build_atomic_base (unsigned_intQI_type_node);
atomicHI_type_node = build_atomic_base (unsigned_intHI_type_node);
atomicSI_type_node = build_atomic_base (unsigned_intSI_type_node);
atomicDI_type_node = build_atomic_base (unsigned_intDI_type_node);
atomicTI_type_node = build_atomic_base (unsigned_intTI_type_node);
and on the branch that code instead looks something like:
#define SET_ATOMIC_TYPE_NODE(TYPE, MODE, DEFAULT) \
(TYPE) = build_atomic_base (DEFAULT, targetm.atomic_align_for_mode
(MODE));
SET_ATOMIC_TYPE_NODE (atomicQI_type_node, QImode,
unsigned_intQI_type_node);
<...>
which provides a target hook to override the default values and a target
can set them to whatever it deems necessary.
There was insufficient time to test and fully flush this out, so it
hasn't made it into mainline. Its only thanks to Josephs heroic efforts
we have C11 :-)
I don't think its a lot of code if you wanted to fool with it for your port.
Andrew
