https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, I think it is IPA-ICF.
What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
where the
inline part does what is actually different among the functions, i.e. the
tests which among other do the early out for
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (length&7)!=0
among other things, and then the *.part.0 parts which are exactly the same for
the 3 functions IL wise, except for the unfortunately differences in the
ranges.
So, essentially just
<bb 2> [local count: 132713219]:
_2 = length_1(D) != 0;
_5 = inData_3(D) != outData_4(D);
_6 = _2 & _5;
if (_6 != 0)
goto <bb 3>; [33.00%]
else
goto <bb 4>; [67.00%]
<bb 3> [local count: 43795362]:
# RANGE [irange] unsigned int [N, 2147483647] MASK 0x7ffffffe VALUE 0x0
length.43_7 = (unsigned int) length_1(D);
# USE = anything
# CLB = anything
memcpy (outData_4(D), inData_3(D), length.43_7);
<bb 4> [local count: 132713219]:
<bb 5> [local count: 132713219]:
# RANGE [irange] int [0, 0][N, +INF] MASK 0x7fffffff VALUE 0x0
# _8 = PHI <length_1(D)(4)>
return _8;
where N is 2, 4 or 8.
Now IPA-ICF comes, doesn't care about ranges, merges all 3 into one and picks
there
the most unfortunate case, the case from the copyData64 part with N 8.
Later on we inline this back into the functions, the function splitting was
useless.
So, the question is what to do in IPA-ICF. Should we punt on range
differences, reset all ranges or try to merge the ranges from all the functions
merged together?
I think the last would be best.
