[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Apr 16 12:30:41 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
inline bool
irange::varying_p () const
{
if (legacy_mode_p ())
return m_kind == VR_VARYING;
if (m_num_ranges != 1)
return false;
tree l = m_base[0];
tree u = m_base[1];
tree t = TREE_TYPE (l);
unsigned prec = TYPE_PRECISION (t);
signop sign = TYPE_SIGN (t);
if (INTEGRAL_TYPE_P (t))
return (wi::to_wide (l) == wi::min_value (prec, sign)
&& wi::to_wide (u) == wi::max_value (prec, sign));
if (POINTER_TYPE_P (t))
return (wi::to_wide (l) == 0
&& wi::to_wide (u) == wi::max_value (prec, sign));
return true;
is truly excessive for !legacy_mode_p () ..., I think the pointer vs.
int case is premature optimization and we might see more inlining
and optimization when doing unconditional
return (wi::to_wide (l) == wi::min_value (prec, sign)
&& wi::to_wide (u) == wi::max_value (prec, sign));
possibly there are simply too many varying_p calls as well. Like
inline bool
range_includes_zero_p (const irange *vr)
{
if (vr->undefined_p ())
return false;
if (vr->varying_p ())
return true;
return vr->may_contain_p (build_zero_cst (vr->type ()));
also
inline value_range_kind
irange::kind () const
{
if (legacy_mode_p ())
return m_kind;
if (undefined_p ())
return VR_UNDEFINED;
if (varying_p ())
return VR_VARYING;
return VR_RANGE;
looks like quite expensive. IMHO since we have m_kind we should
keep it up-to-date and make those checks cheap.
And kill that legacy_mode_p () stuff!?
More information about the Gcc-bugs
mailing list