From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68377 invoked by alias); 4 Aug 2015 09:48:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 68231 invoked by uid 89); 4 Aug 2015 09:48:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: cam-smtp0.cambridge.arm.com Received: from fw-tnat.cambridge.arm.com (HELO cam-smtp0.cambridge.arm.com) (217.140.96.140) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 04 Aug 2015 09:48:56 +0000 Received: from arm.com (e106375-lin.cambridge.arm.com [10.2.207.23]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with ESMTP id t749mpN7004630; Tue, 4 Aug 2015 10:48:51 +0100 Date: Tue, 04 Aug 2015 09:48:00 -0000 From: James Greenhalgh To: Jiong Wang Cc: gcc-patches Subject: Re: [AArch64] Improve TLS Descriptor pattern to release RTL loop IV opt Message-ID: <20150804094851.GA12175@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00151.txt.bz2 On Tue, Jul 28, 2015 at 02:12:36PM +0100, Jiong Wang wrote: > > The instruction sequences for preparing argument for TLS descriptor > runtime resolver and the later function call to resolver can actually be > hoisted out of the loop. > > Currently we can't because we have exposed the hard register X0 as > destination of "set". While GCC's RTL data flow infrastructure will > skip or do very conservative assumption when hard register involved in > and thus some loop IV opportunities are missed. > > This patch add another "tlsdesc_small_pseudo_" pattern, and avoid > expose x0 to gcc generic code. > > Generally, we define a new register class FIXED_R0 which only contains register > 0, so the instruction sequences generated from the new add pattern is the same > as tlsdesc_small_, while the operand 0 is wrapped as pseudo register that > RTL IV opt can handle it. > > Ideally, we should allow operand 0 to be any pseudo register, but then > we can't model the override of x0 caused by the function call which is > hidded by the UNSPEC. > > So here, we restricting operand 0 to be x0, the override of x0 can be > reflected to the gcc. > > OK for trunk? OK. Thanks, James