From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120749 invoked by alias); 27 Oct 2015 10:18:45 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 120239 invoked by uid 48); 27 Oct 2015 10:18:41 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd Date: Tue, 27 Oct 2015 10:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 5.2.1 X-Bugzilla-Keywords: ra, wrong-code X-Bugzilla-Severity: major X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2015-10/txt/msg02219.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 --- Comment #31 from Richard Biener --- (In reply to Richard Henderson from comment #28) > (In reply to Richard Biener from comment #26) > > Hmm, I don't see this documented anywhere. In fact there is no such > > thing as a "vector register", there are only vector modes. And we > > are using %xmm for plain SF/DFmode all over the place. > > > > Note that in the particular case the mode we subreg is TImode, > > not a vector mode. > > You're right, my language was sloppy. The problem I describe is going > to be true for any register whose reg_raw_mode is larger than word_mode. > > The assumption is that assignment to a word_mode subreg both (1) cannot > affect bits outside the word_mode and (2) can be simplified to a plain > hard register post-reload. > > Part deux is impossible when reg_raw_mode is larger than word_mode, > because the subreg-y assignment result is indistinguishable from a > normal word_mode assignment. > > > That may be a workaround for x86 but I don't see how this fixes the > > issue in general given that targets may have general registers larger > > than word_mode > > It doesn't fix other targets, true. But I don't see how to do that > without changes to each target. Drop (2)? But that requires to touch every target as well I guess (and can't be done incrementally). If we go with your fix can you please amend the documentation to mention this problem and suggest what targets need (not) to do to not run into this problem? > > (is x32 TARGET_64BIT?). > > Yes.