[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