From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11322 invoked by alias); 29 Oct 2002 20:48:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11253 invoked from network); 29 Oct 2002 20:48:03 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 29 Oct 2002 20:48:03 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id B56AB4F9B6; Tue, 29 Oct 2002 21:48:02 +0100 (CET) Date: Tue, 29 Oct 2002 12:48:00 -0000 From: Jan Hubicka To: Jan Hubicka Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, rth@redhat.com Subject: Re: Fix x86-64 PIC Message-ID: <20021029204802.GB26265@atrey.karlin.mff.cuni.cz> References: <20021029192314.GG23564@kam.mff.cuni.cz> <20021029153915.G10988@devserv.devel.redhat.com> <20021029204107.GA26265@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021029204107.GA26265@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-10/txt/msg01798.txt.bz2 > > On Tue, Oct 29, 2002 at 08:23:14PM +0100, Jan Hubicka wrote: > > > > > > Hi, > > > I've found that we generate lousy code for x86-64 PIC because we refuse any > > > symbolic addresses in address operand. > > > This patch reorders the checks to be done in proper order (IE do not check > > > sign_extended_value for values otherwise special cased for PIC) > > > > Could you please post some testcases of source lousy code? > > I'd like to know what valid 32-bit sign extended values my recent x86_64_sign_extended_value > > changes don't catch. > > static int t; > q() > { > t=1; > } > &t is not sign_extended_value, but t(%rip) is valid and recognized by the > pic_operand later. It also looks like you've added following hunk to sign_extended_value: if (GET_CODE (XEXP (value, 0)) == UNSPEC && XVECLEN (XEXP (value, 0), 0) == 1 && XINT (XEXP (value, 0), 1) == 15) return 1; This is invalid. We can't accept GOTPCREL references as sign extended values. For instance you can use GOTPCREL in construction like mov $addr%GOTPCREL(%ri), %reg Sign_extended_value should really return 1 only for cases that can be encoded in sign extended immediate fields, that are also used in memory addresses except for RIP relative ones that are special case. Honza