On Tue, Jan 15, 2019 at 4:43 PM Frank Tetzel <s1445...@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.
