On Wed, Sep 28, 2011 at 9:13 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote: >> From: Maxim Kuvyrkov <ma...@codesourcery.com> >> Date: Thu, 29 Sep 2011 07:58:01 +1300 >> >> > To summarize, your opinion seems to be to not enable the >> > optimization by default, correct? >> >> Yes, and I don't think we ever could do so. >> >> BTW, another common paradigm is using the "always clear" bits of a >> pointer to encode state bits. > > Yeah, I think it is a bad optimization that is going to break lots of code > and the glibc patch is definitely unacceptable (and not doing what you think > it is doing, your change didn't do anything at all, as the aligned attribute > applies to the pointer type and not to the pointed type). > > The alignment of the argument pointer can be IMHO only hard assumed > if there is a load or store using that type dominating the spot where you > are checking it, and the target is strict alignment target. > Then we can both assume that alignment, optimize away tests on the low bits > etc. > Otherwise, what you could do is just use the pointed type's alignment as > a hint, likely alignment, e.g. on non-strict alignment target you could > expand code optimistically assuming that it is very likely aligned, but > still shouldn't optimize away low bits tests.
There is nothing like "very likely aligned" ;) Note that what is new is that we now no longer assume alignment by default (we did in the past) and that we derive properties about the pointer _value_ from alignment. I think we can derive pointer values when we see dereferences, the code wouldn't be portable to strict-alignment targets otherwise. We can offer a -fno-strict-alignment option to disable deriving alignment from types. Richard. > Jakub >
