From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24745 invoked by alias); 1 Jun 2015 18:01:09 -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 24692 invoked by uid 89); 1 Jun 2015 18:01:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail-vn0-f42.google.com Received: from mail-vn0-f42.google.com (HELO mail-vn0-f42.google.com) (209.85.216.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 01 Jun 2015 18:01:04 +0000 Received: by vnbf62 with SMTP id f62so17181496vnb.7 for ; Mon, 01 Jun 2015 11:01:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qXOAb3vLm3i0a9NgwwqugicnRD1G1xYJHofhGsQYmAw=; b=bhZixaZzrdvGYgDg0/SB8KRmVSh/89R2hc6BY6jrHBbYmPdv+lRAX5BntViRcyuOoD q1Rx9PfzaZMfGsAqwFmRBSpNCD7h8Cczl6SMOoE4owXOCj6yUuPOuFOY6GcBk//6ZzQk d6/oQSCQTTk7Gr3/34rZ2/24venHFHWgxzb6ZGbSpkyPQpLhS4lLbvHUuJviaQ7Ib0x+ YPCLZ22FdP3xrC/FomXw/AqqN1UKnKZT6L/42MTXn5l0lfqS0vOYbjMzEZvDzmNS5pBm th1c0Cwjwcua45cKN3UM92bq7ggZLAioRDuN3nuYbAJB+SKOnO2/l4sDGx44eOAewFHm tuzQ== X-Gm-Message-State: ALoCoQmSIOMusEmkRqTcfTVDzSRUbmWfeQ0HmsV77FBMt9+l17Mq1+mR0TXVNGmmYtH7HJWw4aUv MIME-Version: 1.0 X-Received: by 10.52.240.198 with SMTP id wc6mr30501575vdc.34.1433181662093; Mon, 01 Jun 2015 11:01:02 -0700 (PDT) Received: by 10.52.231.35 with HTTP; Mon, 1 Jun 2015 11:01:01 -0700 (PDT) In-Reply-To: <556C16B1.5080606@arm.com> References: <20150529193552.GA52215@kam.mff.cuni.cz> <556C16B1.5080606@arm.com> Date: Mon, 01 Jun 2015 18:01:00 -0000 Message-ID: Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt= From: Sriraman Tallam To: Ramana Radhakrishnan Cc: Jan Hubicka , "H.J. Lu" , Pedro Alves , Michael Matz , David Li , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00101.txt.bz2 On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan wrote: > >>> Why isn't it just an indirect call in the cases that would require a GOT >>> slot and a direct call otherwise ? I'm trying to work out what's so >>> different on each target that mandates this to be in the target backend. >>> Also it would be better to push the tests into gcc.dg if you can and >>> check >>> for the absence of a relocation so that folks at least see these as being >>> UNSUPPORTED on their target. >> >> > > > To be even more explicit, shouldn't this be handled similar to the way in > which -fno-plt is handled in a target agnostic manner ? After all, if you > can handle this for the command line, doing the same for a function which > has been decorated with attribute((noplt)) should be simple. -fno-plt does not work for non-PIC code, having non-PIC code not use PLT was my primary motivation. Infact, if you go back in this thread, I suggested to HJ if I should piggyback on -fno-plt. I tried using the -fno-plt implementation to do this by removing the flag_pic check in calls.c, but that does not still work for non-PIC code. > >> I am not familiar with PLT calls for other targets. I can move the >> tests to gcc.dg but what relocation are you suggesting I check for? > > > Move the test to gcc.dg, add a target_support_no_plt function in > testsuite/lib/target-supports.exp and mark this as being supported only on > x86 and use scan-assembler to scan for PLT relocations for x86. Other > targets can add things as they deem fit. > > In any case, on a large number of elf/ linux targets I would have thought > the absence of a JMP_SLOT relocation would be good enough to check that this > is working correctly. > > regards > Ramana > > > > >> >> Thanks >> Sri >> >> >>> >>> >>> >>> Ramana >>>> >>>> >>>>> >>>>> Also I think the PLT calls have EBX in call fusage wich is added by >>>>> ix86_expand_call. >>>>> else >>>>> { >>>>> /* Static functions and indirect calls don't need the pic >>>>> register. */ >>>>> if (flag_pic >>>>> && (!TARGET_64BIT >>>>> || (ix86_cmodel == CM_LARGE_PIC >>>>> && DEFAULT_ABI != MS_ABI)) >>>>> && GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF >>>>> && ! SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0))) >>>>> { >>>>> use_reg (&use, gen_rtx_REG (Pmode, >>>>> REAL_PIC_OFFSET_TABLE_REGNUM)); >>>>> if (ix86_use_pseudo_pic_reg ()) >>>>> emit_move_insn (gen_rtx_REG (Pmode, >>>>> REAL_PIC_OFFSET_TABLE_REGNUM), >>>>> pic_offset_table_rtx); >>>>> } >>>>> >>>>> I think you want to take that away from FUSAGE there just like we do >>>>> for >>>>> local calls >>>>> (and in fact the code should already check flag_pic && flag_plt I >>>>> suppose. >>>> >>>> >>>> Done that now and patch attached. >>>> >>>> Thanks >>>> Sri >>>> >>>>> >>>>> Honza >> >> >