From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55566 invoked by alias); 28 Sep 2015 15:37:22 -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 55555 invoked by uid 89); 28 Sep 2015 15:37:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f49.google.com Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 28 Sep 2015 15:37:20 +0000 Received: by laclj5 with SMTP id lj5so70865797lac.3 for ; Mon, 28 Sep 2015 08:37:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.45.41 with SMTP id j9mr3927341lam.4.1443454636977; Mon, 28 Sep 2015 08:37:16 -0700 (PDT) Received: by 10.25.150.147 with HTTP; Mon, 28 Sep 2015 08:37:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Sep 2015 16:10:00 -0000 Message-ID: Subject: Re: [AArch64] Improve TLS Descriptor pattern to release RTL loop IV opt From: Marcus Shawcroft To: Jiong Wang Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02125.txt.bz2 On 28 July 2015 at 14:12, 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 feels like we are botching the back end to over come a limitation in RTL IV opt. Isn't the real solution in RTL IV opt ? /Marcus > > 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? > > 2015-07-28 Ramana Radhakrishnan > Jiong Wang > > gcc/ > * config/aarch64/aarch64.d (tlsdesc_small_pseudo_): New pattern. > * config/aarch64/aarch64.h (reg_class): New enumeration FIXED_REG0. > (REG_CLASS_NAMES): Likewise. > (REG_CLASS_CONTENTS): Likewise. > * config/aarch64/aarch64.c (aarch64_class_max_nregs): Likewise. > (aarch64_register_move_cost): Likewise. > (aarch64_load_symref_appropriately): Invoke the new added pattern if > possible. > * config/aarch64/constraints.md (Uc0): New constraint. > > gcc/testsuite. > * gcc.target/aarch64/tlsdesc_hoist.c: New testcase. > > -- > Regards, > Jiong >