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