[Tux3] [PATCH 03/10] Fix ileaf aligment

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi at mail.parknet.co.jp> writes:

> Daniel Phillips <phillips at phunq.net> writes:
>
>>> It may work actually, but e.g. arm, mips, superh, generetes alignment
>>> fault, then fault handler checks detail and fix it, or will calls
>>> BUG_ON() if source is kernel.
>>> 
>>> There is no merit to generate alignment fault.
>>
>> I had the impression that gcc is supposed to generate code to access
>> the fields bytewise on architectures that generate alignment faults,
>> when the compiler can't prove statically that the fields are aligned.
>> I could be completely wrong about that...
>
> Um.. We will need to check recent gcc...

I've checked sh5-gcc-3.4 without optimize options. Sorry, it seems you
are right. At least, gcc of sh5 seems to care about that (and seems to
store a byte at a time). Um...

no packed version:
	.loc 1 23 0
	movi	((datalabel ileaf.0 >> 48) & 65535), r2
	shori	((datalabel ileaf.0 >> 32) & 65535), r2
	shori	((datalabel ileaf.0 >> 16) & 65535), r2
	shori	(datalabel ileaf.0 & 65535), r2
	movi	((datalabel inum.1 >> 48) & 65535), r1
	shori	((datalabel inum.1 >> 32) & 65535), r1
	shori	((datalabel inum.1 >> 16) & 65535), r1
	shori	(datalabel inum.1 & 65535), r1
	ld.q	r1, 0, r1
	st.q	r2, 8, r1

packed version:
	.loc 1 22 0
	movi	((datalabel ileaf.0 >> 48) & 65535), r3
	shori	((datalabel ileaf.0 >> 32) & 65535), r3
	shori	((datalabel ileaf.0 >> 16) & 65535), r3
	shori	(datalabel ileaf.0 & 65535), r3
	movi	((datalabel inum.1 >> 48) & 65535), r7
	shori	((datalabel inum.1 >> 32) & 65535), r7
	shori	((datalabel inum.1 >> 16) & 65535), r7
	shori	(datalabel inum.1 & 65535), r7
	ld.q	r7, 0, r1
	andi	r1, 255, r6
	ld.ub	r3, 4, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 4, r1
	ld.q	r7, 0, r1
	shlri	r1, 8, r1
	andi	r1, 255, r6
	ld.ub	r3, 5, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 5, r1
	ld.q	r7, 0, r1
	shlri	r1, 16, r1
	andi	r1, 255, r6
	ld.ub	r3, 6, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 6, r1
	ld.q	r7, 0, r1
	shlri	r1, 24, r1
	andi	r1, 255, r6
	ld.ub	r3, 7, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 7, r1
	ld.q	r7, 0, r1
	shlri	r1, 32, r1
	andi	r1, 255, r6
	ld.ub	r3, 8, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 8, r1
	ld.q	r7, 0, r1
	shlri	r1, 40, r1
	andi	r1, 255, r6
	ld.ub	r3, 9, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 9, r1
	ld.q	r7, 0, r1
	shlri	r1, 48, r1
	andi	r1, 255, r6
	ld.ub	r3, 10, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r6, r63, r1
	or	r2, r1, r1
	st.b	r3, 10, r1
	ld.q	r7, 0, r1
	shlri	r1, 56, r7
	ld.ub	r3, 11, r1
	andi	r1, 0, r1
	add.l	r1, r63, r2
	add.l	r7, r63, r1
	or	r2, r1, r1
	st.b	r3, 11, r1
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3