From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-404909-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12485 invoked by alias); 27 Oct 2012 17:30:45 -0000
Received: (qmail 12277 invoked by uid 48); 27 Oct 2012 17:30:27 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
Date: Sat, 27 Oct 2012 17:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Last reconfirmed Ever Confirmed
Message-ID: <bug-54971-4-8Y8n7Cx19J@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54971-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54971-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-10/txt/msg02585.txt.bz2


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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-27
     Ever Confirmed|0                           |1

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-27 17:30:26 UTC ---
I've checked in a testcase for this, unfortunately it fails on i686-linux
with -Os -m32.
The problem is that for a[0] there is no struct access created at all, as
before esra we have a accesses solely of the form:
  a = *.LC0;
...
  _5 = MEM[(int *)&a + 8B];
...
  MEM[(int *)&a + 8B] = _6;
...
  _8 = MEM[(int *)&a + 4B];
...
  MEM[(int *)&a + 4B] = _9;
...
  D.1370 = *.LC1;
  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})&D.1370];
...
  _13 = MEM[(int *)&a + 8B];
...
  MEM[(int *)&a + 8B] = _14;
...
  _16 = MEM[(int *)&a + 4B];
...
  MEM[(int *)&a + 4B] = _17;
...
  a ={v} {CLOBBER};

i.e. there is no a[0] or MEM[(int *)&a] access, only two whole aggregate
assignments.

I wonder if SRA could create the the extra hole accesses if there are any whole
aggregate writes, at least if there aren't too many (preferrably with sizes
based on the underlying type fields/elements, and not for any padding).
BTW, even for a[1] and a[2] at -Os -m32 there is a problem, on the memcpy we
end up with:
  D.1370 = *.LC1;
  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})&D.1370];
  a$4_3 = MEM[(int[3] *)&D.1370 + 4B];
  # DEBUG a$4 => a$4_3
  a$8_4 = MEM[(int[3] *)&D.1370 + 8B];
  # DEBUG a$8 => a$8_4