Re: Support for NOINLINE attribute

[Rimvydas Jasinskas <rimvydasjas@gmail.com>]

On Fri, Feb 10, 2023 at 11:07 PM Harald Anlauf via Fortran
<fortran@gcc.gnu.org> 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