https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Somehow this constprop function is kept in the IL but not really called by
> anything once IPA passes are done.
This is discovered only when performing inlining on GIMPLE bodies, I
guess during folding of the conditions. At this point, with LTO, the
constprop functions could theoretically be in another partition so
generally it is too late to remove them as unreachable.
(In reply to Jakub Jelinek from comment #7)
> Or perhaps when considering the constprop see that for __first_5(D) being 0B
> there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so
> would invoke UB or likely invoke UB and so not worth constant propagation.
Only when unguarded. Being able to eliminate these when they are
guarded by a NULL check is something that IPA-CP should do. And NULL
checks can be non-obvious at IPA time, in this case this is
essentially done by the check that
if (__first_4(D) != __last_5(D))
where we manage to prove that __first is zero but __last can be either
zero or zero pointer_plus 16 and therefore we fail to propagate (for
all contexts).
I'm afraid I don't have any good ideas that might not lead to adverse
effects in other situations. Perhaps we could specifically track such
comparisons in a bitmap and then do some "likely invalid pointer"
propagation for pointer arithmetics and then avoid cloning for zero
value in presence of such comparisons...
