From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8368 invoked by alias); 6 Apr 2010 17:13:00 -0000 Received: (qmail 8358 invoked by uid 22791); 6 Apr 2010 17:12:58 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Apr 2010 17:12:52 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NzCKY-0008Ec-2k for gcc@gcc.gnu.org; Tue, 06 Apr 2010 13:12:50 -0400 Received: (qmail 18942 invoked from network); 6 Apr 2010 17:12:47 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Apr 2010 17:12:47 -0000 Date: Tue, 06 Apr 2010 17:13:00 -0000 From: Nathan Froyd To: Ian Lance Taylor Cc: roy rosen , gcc@gcc.gnu.org Subject: Re: lower subreg optimization Message-ID: <20100406171245.GK540@codesourcery.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00092.txt.bz2 On Tue, Apr 06, 2010 at 09:58:23AM -0700, Ian Lance Taylor wrote: > In the code the register is always accessed via a subreg, so the > lower-subregs pass thinks that it is OK to decompose the register. > Once it is decomposed, nothing is expected to put it back together. > > To fix this, you should probably look at simple_move in > lower-subreg.c. You will want it to return NULL_RTX for a vector load > or store. Perhaps it should check costs, or perhaps it should never > decompose explicit vector modes. Compiling anything that uses doubles on powerpc e500v2 produces awful code due in part to lower-subregs (the register allocator doesn't help, either, but that's a different story). Code that looks like: rY:DI = r:DI rX:DI = rY:DI (subreg:DF rZ:DI 0) = rX:DI is a hard register for argument passing; the code looks equally awful inside of a function, too. The above gets lowered to: 1: r:SI = r:SI 2: r:SI = r:SI 3: (subreg:SI rX:DI 0) = r:SI 4: (subreg:SI rX:DI 4) = r:SI 5: (subreg:DF rZ:DI 0) = rX:DI which usually results in two stores and a load against the stack, rather than a single-instruction dealing entirely in registers. I realize e500v2 is not exactly a mainstream target, but perhaps a target hook is appropriate here? I suppose checking costs might achieve the same thing. -Nathan