From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115399 invoked by alias); 10 Jan 2019 11:06:41 -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 115383 invoked by uid 89); 10 Jan 2019 11:06:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 11:06:38 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0AB6YRD007997; Thu, 10 Jan 2019 05:06:34 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x0AB6W7W007996; Thu, 10 Jan 2019 05:06:32 -0600 Date: Thu, 10 Jan 2019 11:06:00 -0000 From: Segher Boessenkool To: Alan Modra Cc: gcc-patches@gcc.gnu.org Subject: Re: [RS6000] Emit inline PLT when -mno-tls-markers Message-ID: <20190110110631.GV14180@gate.crashing.org> References: <20190107015844.GI3170@bubble.grove.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190107015844.GI3170@bubble.grove.modra.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00530.txt.bz2 Hi Alan, This patch is okay (for trunk, and backports if needed), thanks! I'll review your other patches next week. Segher On Mon, Jan 07, 2019 at 12:28:44PM +1030, Alan Modra wrote: > I restricted output of inline PLT sequences to when TLS marker relocs > were also available, which is obviously true when just considering > assembler support. However, there is a -mno-tls-markers option to > disable emitting the marker relocs. Currently that option also > disables inline PLT sequences, which is a bug (*). This patch fixes > that problem. > > *) To be honest, it was a deliberate bug. I didn't want to have to > deal with inline PLT __tls_get_addr sequences lacking the marker > relocs in the linker, but it turns out the existing linker support for > old-style __tls_get_addr calls works reasonably well. > > Bootstrapped and regression tested powerpc64le-linux and > powerpc64-linux, with and without -mno-tls-markers. OK to apply? > > * config/rs6000/rs6000.c (rs6000_indirect_call_template_1), > (rs6000_pltseq_template): Guard output of TLS markers with > TARGET_TLS_MARKERS. > (rs6000_longcall_ref, rs6000_call_aix, rs6000_call_sysv), > (rs6000_sibcall_sysv): Ignore TARGET_TLS_MARKERS when deciding > to use inline PLT sequences. > * config/rs6000/rs6000.md (pltseq_tocsave_), > (pltseq_plt16_ha_, pltseq_plt16_lo_), > (pltseq_mtctr_): Don't test TARGET_TLS_MARKERS in predicate.