------- Comment #9 from tsv at solvo dot ru 2005-10-23 18:22 -------
(In reply to comment #8)
> (In reply to comment #7)
> > Can someone try sparc-linux, I would not doubt this could be reproduced
> > there
> > too.
>
> Actually, it can't, as I tried to explain in comment #6, it is probably a
> bug in config/alpha/predicates.md (and it in fact goes away if I remove
> those two lines).
>
By commenting those two lines gcc start to use ldx_u instructions a lot.
If I add simular function to your example like this:
unsigned long f1(struct S *p)
{
return p->c;
}
I get:
f1:
.frame $30,0,$26,0
.prologue 0
ldl $0,8($16)
and $0,0xff,$0
ret $31,($26),1
.end f1
f:
.frame $30,0,$26,0
.prologue 0
lda $1,18($16)
ldq_u $0,18($16)
extbl $0,$1,$0
ret $31,($26),1
.end f
The best case is :) the "f" function should have the same code as "f1" except
the offset should be 18.
After tracing store_bit_field function I came to following:
- if target (pointer to structure) already known and represented as mem/s (reg
...), then "store_bit_field" generates code to access structure member
- if target (pointer to structure) is calculated as same pointer plus offset
and represented as mem/s (reg plus const int...), the "store_bit_bit" just adds
member offset to "const int" (adjust_address) and then works with new offset
which alignment is not known and we get bogus code.
Very good code is generated if I define pointer as volatile:
unsigned long f2(unsigned char *p10)
{
volatile struct S *p = (struct S *) (p10 + 10);
return p->c;
}
the assembler is:
f2:
.frame $30,0,$26,0
.prologue 0
lda $16,10($16)
ldl $0,8($16)
and $0,0xff,$0
ret $31,($26),1
.end f2
(this is simular that gcc 3.4 produces)
So, my opinion that it should be fixed on upper level (somewhere in
store_bit_field function).
Thank you
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
