[Bug libfortran/77278] Use LTO for libgfortran

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278

--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 6 Jun 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
> 
> --- Comment #25 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> (In reply to Jan Hubicka from comment #24)
> > Hi,
> > actually it won't help since C has only one bool type and not bools in
> > different sizes (why would one need that?).
> 
> "Because it's in the Fortran language standard" is probably a good
> answer as any.  For example, the standard specifies that default
> logical and default integer have to have the same size, and
> it specifies all the other logical kinds.
> 
> > I guess it would be easiest to turn Fortran frontend to use integers here.
> 
> Easiest for this case, yes.
> 
> However, this is far from the only case where integer vs. logical
> is a problem in libgfortran - to reduce code size, we've been treating
> them interchangeably for quite some time.
> 
> Really, it would be easiest if there was a way to tell the middle
> end that logical(kind=4) and integer(kind=4) could alias.

I think that's reasonably easy to do for LTO.  We'd want to keep
the default boolean_type_node size BOOLEAN_TYPEs separate but
can glob larger ones with integer types in the canonical type
merging.  We can probably do the same in non-LTO but that might
not be required.

Honza?

> There is another, possibly even worse, case.  To reduce combinatorical
> explosion of some functions, we have been using this idiom
> 
>   mask_kind = GFC_DESCRIPTOR_SIZE (mask);
> 
>   if (mask_kind == 1 || mask_kind == 2 || mask_kind == 4 || mask_kind == 8
> #ifdef HAVE_GFC_LOGICAL_16
>       || mask_kind == 16
> #endif
>       )
>     {
>       /*  Do not convert a NULL pointer as we use test for NULL below.  */
>       if (mptr)
>         mptr = GFOR_POINTER_TO_L1 (mptr, mask_kind);
>     }
>   else
>     runtime_error ("Funny sized logical array");
> 
> where GFOR_POINTER_TO_L1 computes an offset between little- and big-endian
> systems, and we then access the value bytewise.
> 
> If we made this more cleanly, we would add 1505 more functions to the
> libgfortran library (rough count).

If the "bytewise" access uses character types (or uint8_t) then
TBAA wise that should be fine.  If the pointers are restrict
you don't lose optimization either.