On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
>> In the end I'd probably say the patch is ok without the option (thus
>> turned on by default), but if LC_GLOBAL_LOCALE is part of the
>> glibc ABI then we clearly can't do this.
>
> Yes, LC_GLOBAL_LOCALE is part of glibc ABI. I guess we could only assume
> the alignment if the pointer is actually dereferenced on the statement
> that checks the ABI or in some stmt that dominates the spot where you want
> to check the alignment. It is IMHO quite common to pass arbitrary values
> in pointer types, then cast them back or just compare.
Yeah (even if technically invoking undefined behavior in C). Checking if
there is a dereference post-dominating function entry with sth like
FOR_EACH_IMM_USE_STMT (... ptr ...)
if (stmt_post_dominates_entry && contains derefrence of ptr)
alignment = TYPE_ALIGN (...);
and otherwise not assuming anything about parameter alignment might work.
Be careful to check the alignment of the dereference though,
typedef int int_unaligned __attribute__((aligned(1)));
int foo (int *p)
{
int_unaligned *q = p;
return *q;
}
will be MEM[p] but with (well, hopefully ;)) TYPE_ALIGN of TREE_TYPE (MEM[p])
being 1. And yes, you'd have to look into handled-components as well. I guess
you'll face similar problems as we do with tree-sra.c
tree_non_mode_aligned_mem_p
(you need to assume eventually misaligned accesses the same way expansion
does for the dereference, otherwise you'll run into issues on
strict-align targets).
As that de-refrence thing doesn't really fit the CCP propagation you
won't be able
to handle
int foo (int *p)
{
int *q = (char *)p + 3;
return *q;
}
and assume q is aligned (and p is misaligned by 1).
That is, if the definition of a pointer is post-dominated by a derefrence
we could assume proper alignment for that pointer (as opposed to just
special-casing its default definition). Would be certainly interesting to
see what kind of fallout we would get from that ;)
Richard.
> Jakub
>
