public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/51709] New: armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)
@ 2011-12-30  2:27 johnvb at broadcom dot com
  2011-12-30  2:28 ` [Bug target/51709] " johnvb at broadcom dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: johnvb at broadcom dot com @ 2011-12-30  2:27 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-13 18:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-30  2:27 [Bug target/51709] New: armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?) johnvb at broadcom dot com
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

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).