Re: bit fields && data tearing

Peter Hurley
2014-09-05T12:31:06Z

[ +cc linux-arm ]

Hi David,

On 09/05/2014 04:30 AM, David Laight wrote:
> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> It does this because of the more limited range of the offsets for the 16bit access.
> OTOH I don't know if it ever did this for writes - so it may be moot.

Can you recall the particulars, like what ARM config or what code?

I tried an overly-simple test to see if gcc would bump up to the word load for
the 12-bit offset mode, but it stuck with register offset rather than immediate
offset. [I used the compiler options for allmodconfig and a 4.8 cross-compiler.]

Maybe the test doesn't generate enough register pressure on the compiler?

Regards,
Peter Hurley

#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))

struct x {
long unused[64];
short b[12];
int unused2[10];
short c;
};

void store_c(struct x *p, short a[]) {
int i;

for (i = 0; i < ARRAY_SIZE(p->b); i++)
p->b[i] = a[i];
p->c = 2;
}

void store_c(struct x *p, short a[]) {
0: e1a0c00d mov ip, sp
4: e3a03000 mov r3, #0
8: e92dd800 push {fp, ip, lr, pc}
c: e24cb004 sub fp, ip, #4
int i;

for (i = 0; i < ARRAY_SIZE(p->b); i++)
p->b[i] = a[i];
10: e191c0b3 ldrh ip, [r1, r3]
14: e0802003 add r2, r0, r3
18: e2822c01 add r2, r2, #256 ; 0x100
1c: e2833002 add r3, r3, #2
20: e3530018 cmp r3, #24
24: e1c2c0b0 strh ip, [r2]
28: 1afffff8 bne 10 <store_c+0x10>
p->c = 2;
2c: e3a03d05 mov r3, #320 ; 0x140
30: e3a02002 mov r2, #2
34: e18020b3 strh r2, [r0, r3]
38: e89da800 ldm sp, {fp, sp, pc}