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.


             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: link
Be 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).