From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-427118-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31937 invoked by alias); 1 Aug 2013 17:49:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 31847 invoked by uid 48); 1 Aug 2013 17:49:47 -0000
From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58041] Unaligned access to arrays in packed structure
Date: Thu, 01 Aug 2013 17:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wschmidt at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: wschmidt at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58041-4-N3lQpQ5HsB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58041-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58041-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00042.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #11 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Hi Martin,

Your assumptions are correct, but I'm not sure this is the best place to handle
it.  It looks like what you are doing is replacing one already correct memory
reference with another, both of which will generate somewhat nasty code. 
Therefore there isn't much reason to do the transformation at all in the first
place.  I think I would rather analyze the reference when considering adding
the reference to the candidate table, and leaving it out of consideration
altogether.  What do you think?

For example, I'm looking at adding the following ahead of the call to
restructure_reference in slsr_process_ref:

  /* If this reference doesn't meet alignment restrictions, don't
     make it a candidate.  Logic similar to that in tree-ssa-loop-ivopts.c:
     may_be_unaligned_p(), without the STEP check.  */
  if (mode != BLKmode)
    {
      tree base_type = TREE_TYPE (base);
      unsigned base_align = get_object_alignment (base);
      unsigned mode_align = GET_MODE_ALIGNMENT (mode);
      base_align = MAX (base_align, TYPE_ALIGN (base_type));

      if (base_align < mode_align
      || (bitpos % mode_align) != 0
      || (bitpos % BITS_PER_UNIT) != 0)
    return;

      if (offset
      && (highest_pow2_factor (offset) * BITS_PER_UNIT) < mode_align)
    return;
    }