On Wed, 1 Aug 2012, Richard Henderson wrote:
> On 08/01/2012 01:40 AM, Richard Guenther wrote:
> > I see. So your issue is that you don't get the knowledge
> > that the address is even more aligned than required by the
> > builtin.
>
> Yes. Very helpful for quite a few targets that only have word-sized atomic
> operations, and we emulate char/short via bit-fiddling. That's where
> MEM_ALIGN as an align+ofs pair would come in doubly helpful...
>
> > So we only use type information when seeing an actual memory
> > reference where we make sure to keep alignment info correct
> > (which we don't bother to do for addresses).
>
> How hard would it be to include (some) builtins in "actual memory reference"?
> Since it seems likely at this point that gimple_atomic will make it in for
> 4.8?
Actually it would not help you at all. As far as I understand
the testcase is equivalent from an alignment perspective to
struct S { int x; unsigned short y; } g_s;
void bad (S *p_s)
{
short *p = (short *)&p_s->y;
*(short *)p = 0;
}
so the builtin is a memory access to a short. We cannot derive
any alignment for p_s from this alone unless we change the way
the middle-end constrains pointer type usage (which in turn
means that pointer conversions cannot be dropped on the floor
like we do now).
If you said
p_s->y = 0;
then we can exploit the fact that you dereference p_s and derive
bigger alignment. But I don't see how we can massage the
builtin to preserve such form. Well, put in a memory reference
in the argument, __builtin_compare_exchange (p_s->y, ...), but
that fails foul of GIMPLE requirements to use a temporary for
register type function arguments, which we may be able to
overcome with some special flags.
Richard.
