[PATCH, PR43814] Assume function arguments of pointer type are aligned.

[Richard Guenther]

On Thu, Sep 29, 2011 at 11:20 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
>> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
>> >> There is nothing like "very likely aligned" ;)  Note that what is new is
>> >
>> > On non-strict aligned targets there is no reason not to have something like
>> > "very likely aligned".  You would expand stores/loads as if it was aligned
>> > in that case, and if it isn't, all you'd need to ensure from that is that
>> > you don't derive properties about the pointer value from the "likely
>> > aligned" info, only from alignment.
>>
>> As if aligned, say, using movaps? ;)  Then we can as well derive
>> properties about the pointer value.
>>
>> Note that I don't see a real difference between expanding a load/store
>> assuming the pointer is aligned from deriving properties about the pointer
>> value.  To support existing questionable code I'd do both only if
>> there is a dereference post-dominating the pointer assignment of course.
>
> I was talking about e.g. PR49442, where using the unaligned stores has
> severe performance hit.  If compiler was hinted that the store pointers are
> likely aligned, it could version on the alignment.

Well, it could do so anyway?  It just doesn't as the vectorizer cost model
and hw description says using misaligned moves is just fine.

>> > But any references?  If you have
>> > int foo (int *p)
>> > {
>> >  memcpy (p, "a", 1);
>> >  return ((uintptr_t) p & 3) == 0;
>> > }
>> > then even if p isn't aligned, this could work even on strict aligned
>> > targets.
>>
>> Well, the above isn't a "dereference".  Or rather, if it is, it's a dereference
>> through a type with assumed alignment of 1 byte.
>
> If the dereference is only through the declared type of the parameter, I
> feel much safer about it.  But I thought this thread was exactly about
> memcpy/memset with int * pointer not dereferenced in any other way.

Maybe that was the PR the patch is about, but surely we can't treat
a memcpy (p, ..) like *p.  Which means we'd use the declared type
of p only.  And we can do so only for parameters (intermediate conversions
are dropped), which would make the case apply to artificial testcases only
(and thus not worth).

Richard.

>        Jakub
>