Re: Support for NOINLINE attribute

[Harald Anlauf <anlauf@gmx.de>]

Hi Rimvydas,

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

if somebody wants to tackle this approach - defining options for
single translation units or whole modules - fine with me, but I
don't see this high on the priority list.  Besides, attributes are
very compiler dependent beasts.

The annotation of loops and loop nests in gfortran is slightly less
expressive than what I am familiar with when using some commercial
($$$$) compilers, but that uses a different infrastructure within gcc.

> 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.

OpenMP is already explicitly handled in gfortran and follows the
standard.

>
> > - 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 :-)

I am also not a native speaker, like many others contributing, but let
me quote the relevant orignal paragraph:

"The @code{noreturn} keyword tells the compiler to assume that
@code{fatal} cannot return.  It can then optimize without regard to what
would happen if @code{fatal} ever did return.  This makes slightly
better code.  More importantly, it helps avoid spurious warnings of
uninitialized variables."

My reading of this original paragraph differs very much from the
intention I get from the shortened version.  Would you please reread?

> >   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.

True.  And that's the whole point (IMHO), not silencing the compiler.

> > - 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.

But shouldn't we rather follow what the C family of compilers in the
first place does for a particular target?  Most relevant libraries
for Fortran code are either C/C++ or Fortran anyway, including any
of the common MPI implementations, so should we care about Ada?

I normally work on platforms where weak symbols are supported,
but maybe someone else has an opinion on it.

> 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.

Frankly, I think that would really look ugly, besides the fact that
a platform either does support weak symbols or not, independent of
the symbol.

> 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?

I think a single patch would be fine.

Thanks for working on this!

Harald

> Regards,
> Rimvydas
>