From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40522 invoked by alias); 26 Jul 2019 17:39:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 40509 invoked by uid 89); 26 Jul 2019 17:39:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=welcomed, UD:ipa-icf.c, ipa-icf.c, leaning X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Jul 2019 17:39:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F3A89337; Fri, 26 Jul 2019 10:39:51 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.39]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7E8793F694; Fri, 26 Jul 2019 10:39:51 -0700 (PDT) From: Richard Sandiford To: Jozef Lawrynowicz Mail-Followup-To: Jozef Lawrynowicz ,gcc@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc@gcc.gnu.org Subject: Re: [RFC] Disabling ICF for interrupt functions References: <20190719134511.3d9101e5@jozef-kubuntu> Date: Fri, 26 Jul 2019 17:39:00 -0000 In-Reply-To: <20190719134511.3d9101e5@jozef-kubuntu> (Jozef Lawrynowicz's message of "Fri, 19 Jul 2019 13:45:11 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00175.txt.bz2 [Catching up after being away, sorry if this has already been resolved.] Jozef Lawrynowicz writes: > For MSP430, the folding of identical functions marked with the "interrupt" > attribute by -fipa-icf-functions results in wrong code being generated. > Interrupts have different calling conventions than regular functions, so > inserting a CALL from one identical interrupt to another is not correct and > will result in stack corruption. > > I imagine there are other targets that also have different calling conventions > for interrupt functions compared to regular functions, and so folding them > would be undesirable. > > Therefore, I would appreciate some feedback as to whether it would be welcomed > to fix this in a generic way or if I should just keep it MSP430 specific. > > 1. MSP430 specific > Add the "no_icf" attribute to functions marked with the "interrupt" attribute > when processing them in the backend. > > 2. Target Hook > Add a DEFHOOKPOD (e.g. TARGET_NO_INTERRUPT_ICF) which controls whether ICF is > disabled for functions with the interrupt attribute (in gcc/ipa-icf.c, where > "no_icf" attribute is processed). This sounds like it should be a question about two functions rather than one, i.e.: can functions A and B be merged together if they appear to be identical at some level? I think for most targets, merging two identical interrupt functions would be OK. It's merging an interrupt and non-interrupt function that's the problem. So maybe we need something like targetm.can_inline_p, but for merging rather than inlining? The function would need to be transitive of course. Thanks, Richard > 3. Always on > Same as 2. but without the hook implementation - just check for the interrupt > attribute and disable ICF if it is present. > > I'm personally leaning towards option 2, target hook, since other targets may > benefit from this. > > Thanks, > Jozef