public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "johnvb at broadcom dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/51709] New: armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?) Date: Fri, 30 Dec 2011 02:27:00 -0000 [thread overview] Message-ID: <bug-51709-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51709 Bug #: 51709 Summary: armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?) Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: johnvb@broadcom.com armv7 target is not always producing unaligned access to packed fields using the appropriate half and full word instructions. Rather sometimes it uses bytes accesses with shifts and or's. Below is a program which produces the problem: typedef unsigned char uint8; typedef unsigned short uint16; typedef unsigned int uint32; #define HALFWORD 1 #define ADD_BYTE 0 #define PACKED 1 #if HALFWORD #define FIELD_T uint16 #else #define FIELD_T uint32 #endif #if PACKED #define PACKED_ATTRIBUTE __attribute__ ((packed)) #else #define PACKED_ATTRIBUTE #endif typedef struct PACKED_ATTRIBUTE { #if ADD_BYTE uint8 field0; #endif FIELD_T field1; FIELD_T field2; } packed_struct_t; typedef struct { #if ADD_BYTE uint8 field0; #endif FIELD_T field1; FIELD_T field2; } natural_struct_t; void test_function(natural_struct_t *natural, packed_struct_t *packed) { natural->field1 = packed->field1; packed->field2 = natural->field2; } This produces test_function: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldrb r3, [r1, #1] @ zero_extendqisi2 @ tmp141, ldrb ip, [r1, #0] @ zero_extendqisi2 @ tmp140,* packed orr r2, ip, r3, lsl #8 @, tmp143, tmp140, tmp141, ldrh r3, [r0, #2] @, natural_3(D)->field2 strh r2, [r0, #0] @ movhi @ tmp143, natural_3(D)->field1 strh r3, [r1, #2] @ unaligned @ natural_3(D)->field2, bx lr @ .size test_function, .-test_function .ident "GCC: (Sourcery CodeBench Lite 2011.09-69) 4.6.1" The load from the packed structure is decomposed to byte accesses but note the stores are not. Also if you try full words by changing the define HALFWORD the generated code is as expected. Adding a byte to the beginning of the packed and natural structure by changing the define ADD_BYTE doesn't change the results. It appears to only be the half word load that is having the problem. Note in the above assembly output, that the @unaligned is missing from the load though present on the store. If you look at the assembly for the full word compile, the @unaligned is present on both the load and store. I claim this is a sometimes result because I have looked at cases in my more complicated source and I can see that sometimes packed half word loads do not use byte accesses.
next reply other threads:[~2011-12-30 2:14 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-12-30 2:27 johnvb at broadcom dot com [this message] 2011-12-30 2:28 ` [Bug target/51709] " johnvb at broadcom dot com 2011-12-30 2:28 ` johnvb at broadcom dot com 2011-12-30 3:24 ` johnvb at broadcom dot com 2012-01-13 15:41 ` ramana at gcc dot gnu.org 2012-01-13 18:59 ` johnvb at broadcom dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-51709-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).