Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

[Richard Guenther <rguenther at suse dot de>]

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.