From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54824 invoked by alias); 12 Sep 2016 19:45:52 -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 54812 invoked by uid 89); 12 Sep 2016 19:45:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=som, UD:aarch64.h, aarch64h, aarch64.h X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Sep 2016 19:45:41 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEDEB2B97EE; Mon, 12 Sep 2016 19:45:40 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CJje69024241; Mon, 12 Sep 2016 15:45:40 -0400 Subject: Re: [patch v2] Get rid of stack trampolines for nested functions (3/4) To: Eric Botcazou , gcc-patches@gcc.gnu.org References: <1518726.5fkcUnkpqM@arcturus.home> <2332440.uHF5nx4qG9@arcturus.home> From: Jeff Law Message-ID: <5a79207c-b0f9-790a-d8a3-169d6f19a868@redhat.com> Date: Mon, 12 Sep 2016 19:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2332440.uHF5nx4qG9@arcturus.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00662.txt.bz2 On 09/04/2016 02:14 PM, Eric Botcazou wrote: > These are the individual back-end changes. Only the architectures for which > native platforms are available are changed for now. The changes were tested > at AdaCore over the years for every architecture and I'll retest them if they > are accepted, except for those I cannot access any more (Alpha, MIPS, PA). > > > 2016-07-04 Eric Botcazou > > * config/aarch64/aarch64.h(TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Define > * config/alpha/alpha.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Likewise. > * config/arm/arm.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise. > * config/arm/arm.c (arm_function_ok_for_sibcall): Return false for an > indirect call by descriptor if all the argument registers are used. > (arm_relayout_function): Use FUNCTION_ALIGNMENT. > * config/i386/i386.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Define. > * config/ia64/ia64.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise. > * config/mips/mips.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise. > * config/pa/pa.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise. > * config/rs6000/rs6000.h(TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Likewise > * config/sparc/sparc.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Likewise. > I'm going to let the target maintainers own this. Hell, I can't even remember if the PA port exclusively uses procedure descriptors. It certainly did for 32bit SOM, but there's the 32bit portable runtime, fast-indirect-calls and the 64bit runtimes to ponder. John probably remember this stuff far better than I. Jeff