https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Confirmed. This is a missed optimization, we fail to optimize the loop guard
>
> <bb 16> [local count: 329643239]:
> _4 = (unsigned long) &MEM <char[3]> [(void *)&str + 2B];
> _6 = (unsigned long) __i_14;
> _50 = -_6;
> _100 = _4 + 18446744073709551615;
> _40 = _100 - _6;
> _41 = _40 > 13;
> if (_41 != 0)
Do we even get a non-zero range for _4? I'm assuming that even if we get that,
we can't see that &str+2B minus 1 is also nonzero?
>
> with __i_14 being
>
> <bb 11> [local count: 452186132]:
> # __i_14 = PHI <&MEM <char[3]> [(void *)&str + 1B](10), &MEM <char[3]>
> [(void *)&str + 2B](9)>
>
> I'll note that the strlen pass runs before VRP (but after DOM), but I'll
> also note that likely ranger isn't very good with these kind of
> "symbolic" ranges? How would we handle this? Using two
> relations, __i_14 >= &str + 1 && __i_14 <= &str + 2?
Yeah, we don't do much with that. Although the pointer equivalency class
should help in VRP's case. We do some simple pointer tracking and even call
into gimple fold to simplify statements, but it's far from perfect and as you
say, strlen is running before VRP, so it wouldn't help in this case.
>
> DOM has
>
> Optimizing block #16
>
> 1>>> STMT 1 = &MEM <char[3]> [(void *)&str + 2B] ge_expr __i_14
> 1>>> STMT 1 = &MEM <char[3]> [(void *)&str + 2B] ne_expr __i_14
> 1>>> STMT 0 = &MEM <char[3]> [(void *)&str + 2B] eq_expr __i_14
> 1>>> STMT 1 = &MEM <char[3]> [(void *)&str + 2B] gt_expr __i_14
> 1>>> STMT 0 = &MEM <char[3]> [(void *)&str + 2B] le_expr __i_14
> Optimizing statement _4 = (unsigned long) &MEM <char[3]> [(void *)&str + 2B];
> LKUP STMT _4 = nop_expr &MEM <char[3]> [(void *)&str + 2B]
> 2>>> STMT _4 = nop_expr &MEM <char[3]> [(void *)&str + 2B]
> Optimizing statement _6 = (unsigned long) __i_14;
> LKUP STMT _6 = nop_expr __i_14
> 2>>> STMT _6 = nop_expr __i_14
> Optimizing statement _50 = -_6;
> Registering value_relation (_6 pe64 __i_14) (bb16) at _6 = (unsigned long)
> __i_14;
> LKUP STMT _50 = negate_expr _6
> 2>>> STMT _50 = negate_expr _6
> Optimizing statement _100 = _4 + 18446744073709551615;
> LKUP STMT _100 = _4 plus_expr 18446744073709551615
> 2>>> STMT _100 = _4 plus_expr 18446744073709551615
> Optimizing statement _40 = _100 - _6;
> Registering value_relation (_100 < _4) (bb16) at _100 = _4 +
> 18446744073709551615;
> LKUP STMT _40 = _100 minus_expr _6
> 2>>> STMT _40 = _100 minus_expr _6
> Optimizing statement _41 = _40 > 13;
> LKUP STMT _41 = _40 gt_expr 13
> 2>>> STMT _41 = _40 gt_expr 13
> LKUP STMT _40 le_expr 14
> Optimizing statement if (_41 != 0)
>
> Visiting conditional with predicate: if (_41 != 0)
>
> With known ranges
> _41: [irange] bool VARYING
Ranger won't do anything, but can DOM's scoped tables do anything here? The
hybrid threader in DOM first asks DOM's internal mechanism before asking ranger
(which seems useless in this case):
dom_jt_simplifier::simplify (gimple *stmt, gimple *within_stmt,
basic_block bb, jt_state *state)
{
/* First see if the conditional is in the hash table. */
tree cached_lhs = m_avails->lookup_avail_expr (stmt, false, true);
if (cached_lhs)
return cached_lhs;
/* Otherwise call the ranger if possible. */
if (state)
return hybrid_jt_simplifier::simplify (stmt, within_stmt, bb, state);
return NULL;
}
Our long term plan for pointers was providing a prange class and separating
pointers from irange. This class would track zero/nonzero mostly, but it would
also do some pointer equivalence tracking, thus subsuming what we do with
pointer_equiv_analyzer which is currently restricted to VRP and is an
on-the-side hack.
The prototype I had for it last release tracked the equivalence plus an offset,
so we should be able to do arithmetic on a prange of say [&str + X]. I had to
put it aside because the frange work took way longer than expected, plus legacy
got in the way. Neither of this is an issue now, so we'll see.. but that's the
plan. I should dust off those patches :-/.
