From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id 4CD483858414 for ; Fri, 10 Feb 2023 22:17:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CD483858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-16aa71c1600so8463832fac.11 for ; Fri, 10 Feb 2023 14:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yY5sPMbtmvdEJropMYONls+BogulLmzyYQ2LTr6wxYs=; b=dKoK0Hk4Z0286sAtpcS6viagS2EG6JGlTtDIjvX8iK0GVP6P1Wn5o4kLuL1REiqtwu hSPtIp2/VK2tY/9KscGKjoDldufaRRjH36adTmvlCnyD3ETtyDcML5jgvorhwYSJuMXx EGf3QjdV16qNQ7uzoN3wljtygzby+gK4Vcr1gHNZHPxVaZPcufDzLbyeMhSv8Wnfzz3j ecw1M6cpifHTEJV/xe9lV7yeVwoSfHmkC3ONneT6/lK3vpDBm6RtNxsdFkKlHkZQMen+ pTKaMQ+tqMVoCYHyeLAghq85H3TPahJvGdGusq5hY5gjUQ9yRjSitrYjpSPAldUq8Ij3 hbGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yY5sPMbtmvdEJropMYONls+BogulLmzyYQ2LTr6wxYs=; b=sgvKJ9nU3+eRYVw3wAX+9e1OZhNLc5Vqd3o1+jxgabsUpjjPS4HZq9w4YKuPHi2uz1 lFzjRvjEe6r7mSXrYjMCSO10jux7Pj3iUTqCpE8D2pnv5Xn/26c0qoOP+RhyirFa7rfx nUh8HPnGY0oPEV9CPZ91vrLeveKQKCWhhvAmQEo46GThd+GdNj+vKiZ2Wf2jznIT7G7A EPdqlZ5KAuEk69eHp4jpF9xZFQOR2EtxcSqJi3JN/9wY6KfbRT6A5TT13S1xHNTvloSX OhfytMPHajtPXRI3d8gfr2pgVy07l5JGg6M7sZiwI6Fn+6c5xygZ7fNKucQq1ngd1bUF mGVw== X-Gm-Message-State: AO0yUKV9R7BdS+XvG+NzpkZyYYPn0WGH17TmF/nWaV8B2FhuQI0xpyvu TbhKckYK1TeoZud9lcK/TWn+u+2GtQaK04jvWiE= X-Google-Smtp-Source: AK7set8Rj/XqgSUvoNA74Kfof/aM9wrrX+HxH0TrgTdCSGMYgJ3Kr7g/t9Kz5a3iBhf7ZspJ67yn8FwV3PKmtyd98uE= X-Received: by 2002:a05:6870:961d:b0:163:5c6d:46bc with SMTP id d29-20020a056870961d00b001635c6d46bcmr2560664oaq.299.1676067420146; Fri, 10 Feb 2023 14:17:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rimvydas Jasinskas Date: Sat, 11 Feb 2023 00:16:55 +0200 Message-ID: Subject: Re: Support for NOINLINE attribute To: Harald Anlauf Cc: fortran Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 10, 2023 at 11:07 PM Harald Anlauf via Fortran wrote: > I actually like the idea of supporting the suggested attributes, > provided they work and behave the same way with and without LTO. All these three declaration attributes apply the same regardless of LTO, LTO just expands what optimizations see during link time. >-NOINLINE: I disagree with Steve here; we shouldn't invent a new > syntax (noinline on/off), and rather follow what other compilers > provide (INLINE/NOINLINE). It would also be very complicated to implement this, attribute applies to declaration and not the use location. Way better would be just to forward optimization pragmas see https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html say !GCC$ OPTIMIZE "-O1" subroutine foo() .... !GCC$ OPTIMIZE "-O2" subroutine bar(), or maybe even !GCC$ push_options subroutine foor()... end subroutine !GCC$ pop_options However I have no idea where to even start looking to get these working (this would be location based pragmas). NOINLINE already took me quite some time to study other gcc frontends while trying to find where it could be hooked in gfortran frontend. There could be other special cases in the code where attributes need to be applied explicitly again, say OMP. > - NORETURN: this is an important attribute, as your testcases show. > However: > > +@item @code{NORETURN} -- add hint that given function cannot return. This > +makes slightly better code. More importantly, it helps avoid spurious warnings > +of uninitialized variables. > > I would not claim "This makes slightly better code", but rather > that it provides additional optimiztion opportunities. I took those from gcc/doc/extend.texi:25383 with a bit of shortening. I'm not a native speaker, so it is hard for me to condense information into short readable descriptions :-) > Can you explain why you wrote that it should help to "avoid spurious > warnings of uninitialized variables"? While this attribute does provide > a useful hint to the compiler, a user should not focus on that attribute > just to silence the compiler. Same, from extend.texi, see gcc/testsuite/gfortran.dg/noreturn-3.f90 It is about marking dead conditional branches, so that the compiler can prove proper initialization (no -Wmaybe-uninitialized given). It should behave the same as in C frontend. > - WEAK: I do not like the way it is coded in the provided patch. > If a target does not support it, we should not generate an error, > but rather emit a warning that it is not supported. > It appears that declare_weak() already does that. I took the idea from Ada frontend see gcc/ada/gcc-interface/utils.cc:7210 I would generally prefer a hard error here, libraries like MPI could break spectacularly if weak symbols would get emitted as global. Maybe it would be better later add support to use the trick from finclude/math-vector-fortran.h like: !GCC$ ATTRIBUTES weak :: SYM if('x86_64') just an idea, but i'm fine with anything allowing me not sed "/SYM/s/.globl/.weak/" through assembly intermediates in makefile rules. Once the fine details get ironed out I could prepare patch series of each attribute as its own separate patch, but given the proximity of changes locations maybe a single patch is OK? Regards, Rimvydas