From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 3FCF63858034 for ; Fri, 25 Jun 2021 19:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3FCF63858034 Received: by mail-lf1-x135.google.com with SMTP id u13so17945540lfk.2 for ; Fri, 25 Jun 2021 12:00:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TKXqL4JVSiuPVBiHNMTU84yLVywhZW+3B4g5OGQy9QQ=; b=oVBz0gHoTzGEEyN0NGInnwrqHx1010aCMpJL6+TJN5wS24H3mAur+JiZbxz++YYOur nB2CfRIXPmmDZnng9ZiQw0tYNOp2V1KUwi1BDbfC7f7LMyUdrPdSOv4mmBl+J+HkYb6T lJzFhVuvxj14yNu2GFAMg1oGOs/ROU0L6KsdpLUQriJQZHqTRqUDlE1Qa0DfQ9n4rV9O 3tpfan3BeokYNom5R2CFBi/3P5WmasVwS8NuVyNlfDwgexbCMwvV6tUnDenCzRiLTMLI g1ZKD1GBdvPaR5I9GZYjl6ShpVYZfJ3UcJ51ZNpaPUmusdqoGZTpz12hBaEMlp2NvDUR WrYA== X-Gm-Message-State: AOAM532/0ho4MCyiJpVXfTt1gWsGux7tKHOBKVmsocWs+wuxYgpdjgfY NrIO7B+uiDOqt9TnWwwF5qxS5yogM/iXdBpFM6XePA== X-Google-Smtp-Source: ABdhPJwjtKjzwDqardQINnva9iT83QOERrWrt6FBChpFtw2zKNSuAsdFWQqmVhMV298ramEMwcqg561oiysv5oOS09Y= X-Received: by 2002:a05:6512:3e24:: with SMTP id i36mr8671896lfv.368.1624647638676; Fri, 25 Jun 2021 12:00:38 -0700 (PDT) MIME-Version: 1.0 References: <4a46257d-91cd-427e-1b11-7599ad36d07f@suse.cz> <20210623123841.GC65660@kam.mff.cuni.cz> <7fed627d-7213-918c-3ca6-0db60623a32b@suse.cz> In-Reply-To: <7fed627d-7213-918c-3ca6-0db60623a32b@suse.cz> From: Nick Desaulniers Date: Fri, 25 Jun 2021 12:00:25 -0700 Message-ID: Subject: Re: [PATCH] inline: do not inline when no_profile_instrument_function is different To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Peter Collingbourne , Fangrui Song , Chris Wailes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.8 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 19:00:41 -0000 On Wed, Jun 23, 2021 at 6:15 AM Martin Li=C5=A1ka wrote: > > On 6/23/21 2:38 PM, Jan Hubicka wrote: > > Is there reason to prevent the inlining once instrumentation is done? > > No ;) Here's another case that coincidentally came up yesterday. How should these attributes behave in the case of __attribute__((flatten)) on the caller? Another case which is curious is what happens when the callee has __attribute__((always_inline)) and there's a conflict? In LLVM, the current behavior is: "__attribute__((no_stack_protector)) and __attribute__((no_profile_instrument_function)) will prevent inline substitution when the attributes do not match between caller and callee, unless the callee was attributed with __attribute__((always_inline)) or the caller was attributed with __attribute__((flatten))." We have some overzealous users of always_inline and flatten in Android. They are currently playing whack-a-mole with no_stack_protector. I'm not sure yet how we can better help them self diagnose, or whether we should consider a change in policy. I'm also not sure whether GCC's einliner corresponds with always_inline or not necessarily? -- Thanks, ~Nick Desaulniers