Re: GCC's ICF vs. gold's ICF

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Jan 15, 2019 at 4:43 PM Frank Tetzel
<s1445051@mail.zih.tu-dresden.de> wrote:
>
> > > why is the ICF pass in gcc not folding member functions which
> > > depend on a template parameter but happen to generate identical
> > > code? Is it because it is not identical on the IR level in the
> > > compiler? Can I somehow dump the IR in text form?
> >
> > You can look at the ICF dump generated when you pass
> > -fdump-ipa-icf-details
> >
> > And yes, ICF has to consider IL differences that may result in
> > different allowed followup optimizations while when the IL is final
> > (such as link-time) no such considerations have to be made.  A very
> > simple example would be signed vs. unsigned integer multiplication
> > where from the former IL overflow would be undefined and
> > optimizations can exploit that while not for the latter.
>
> Thanks for the information. If I read the dump correctly, it also
> considers the return type and that seems to be the problem in my tiny
> test program.
>
> snippet from dump:
>
>   group: with 1 classes:
>     class with id: 1, hash: 2170673536, items: 2
>       MyArray<float, 1024>::operator[](unsigned int)/4 MyArray<int, 1024>::operator[](unsigned int)/3
>   false returned: 'alias sets are different' (compatible_types_p:244)
>   false returned: 'result types are different' (equals_wpa:676)
>
> The body of the functions look identical, but the return type differs.
> So in C++, ICF is "disabled" for templated functions with a template
> parameter as return type.
>
> But why is the return type preventing code folding? Because we do not
> know the calling convention at this point in time?

Kind-of.  Probably because ICF is not prepared to "fixup" callers
and insert no-op type conversions to make the IL valid.  Martin should
know.

The analysis could certainly be enhanced to avoid comparing some bits
that will not be relevant in the end.

Richard.