------- Comment #10 from jakub at gcc dot gnu dot org 2005-12-01 16:39 -------
Well, clearly it is not fixed, as proven on stock gcc-4_0-branch with:
/* { dg-do compile } */
/* { dg-options "-m32 -Os -fpic -mtune=pentium4" } */
struct S
{
void *p[30];
unsigned char a0 : 1;
unsigned char a1 : 1;
unsigned char a2 : 1;
unsigned char a3 : 1;
unsigned char a4 : 1;
unsigned char a5 : 1;
unsigned char a6 : 1;
unsigned char a7 : 1;
unsigned char a8 : 1;
unsigned char a9 : 1;
unsigned char a10 : 1;
unsigned char a11 : 1;
unsigned char a12 : 1;
unsigned char a13 : 1;
};
void foo (struct S *x, unsigned char y)
{
if (! x->a12 == y)
{
x->a12 = y;
x->a3 = 0;
x->a5 = 0;
x->a6 = 0;
x->a7 = 0;
x->a8 = 0;
x->a9 = 0;
x->a10 = 0;
x->a11 = 0;
}
}
and eventhough it works on 4.1 branch, there are no signs of it actually being
fixed in any way.
IMHO, if movqi_1 wants to use movl instead of movb or movzbl, it needs to
satisfy
some predicate (whether it is aligned_operand or something else doesn't matter
much) that tells it that the optimization is safe (i.e. won't fall off the
cliff). Another thing is that aligned_operand certainly should use
MEM_ALIGN (), otherwise it will succeed only in far fewer cases than it
really could. What the predicate does ATM can be used as fallback if MEM_ALIGN
(op) < 32. Now, we could perhaps safely use movl even if not aligned,
because i?86 is not a strict alignment target, if we were guaranteed we aren't
at the end of the cliff, but the question is if it is worthwhile in that case.
E.g. we could look at compute_builtin_object_size (MEM_EXPR (op), 2) and if
op is say a pointer to a middle of some structure, then we could safely use
movl.
Is movl a win when the address isn't 32-bits aligned?
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199
