On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek <ja...@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.
> > 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.
Jakub
