From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94240 invoked by alias); 19 Jul 2019 13:32:26 -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 94230 invoked by uid 89); 19 Jul 2019 13:32:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:MSK, H*F:D*ru X-HELO: smtp.ispras.ru Received: from bran.ispras.ru (HELO smtp.ispras.ru) (83.149.199.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Jul 2019 13:32:24 +0000 Received: from monopod.intra.ispras.ru (monopod.intra.ispras.ru [10.10.3.121]) by smtp.ispras.ru (Postfix) with ESMTP id 015AF203C1; Fri, 19 Jul 2019 16:32:21 +0300 (MSK) Date: Fri, 19 Jul 2019 13:32:00 -0000 From: Alexander Monakov To: Jozef Lawrynowicz cc: gcc@gcc.gnu.org Subject: Re: [RFC] Disabling ICF for interrupt functions In-Reply-To: <20190719134511.3d9101e5@jozef-kubuntu> Message-ID: References: <20190719134511.3d9101e5@jozef-kubuntu> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-07/txt/msg00128.txt.bz2 On Fri, 19 Jul 2019, Jozef Lawrynowicz wrote: > 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. But ICF by creating an alias would be fine, correct? As I understand, the real issue here is that gcc does not know how to correctly emit a call to "interrupt" functions (because they have unusual ABI and exist basically to have their address stored somewhere). So I think the solution shouldn't be in disabling ICF altogether, but rather in adding a way to recognize that a function has quasi-unknown ABI and thus not directly callable (so any other optimization can see that it may not emit a call to this function), then teaching ICF to check that when deciding to fold by creating a wrapper. (would it be possible to tell ICF that addresses of interrupt functions are not significant so it can fold them by creating aliases?) Alexander