On Mon, Apr 24, 2023 at 9:44 AM Aldy Hernandez via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> There is a call to contains_p() in ipa-cp.cc which passes incompatible
> types. This currently works because deep in the call chain, the legacy
> code uses tree_int_cst_lt which performs the operation with
> widest_int. With the upcoming removal of legacy, contains_p() will be
> stricter.
>
> OK pending tests?
>
> gcc/ChangeLog:
>
> * ipa-cp.cc (ipa_range_contains_p): New.
> (decide_whether_version_node): Use it.
> ---
> gcc/ipa-cp.cc | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index b3e0f62e400..c8013563796 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -6180,6 +6180,19 @@ decide_about_value (struct cgraph_node *node, int
> index, HOST_WIDE_INT offset,
> return true;
> }
>
> +/* Like irange::contains_p(), but convert VAL to the range of R if
> + necessary. */
> +
> +static inline bool
> +ipa_range_contains_p (const irange &r, tree val)
> +{
> + if (r.undefined_p ())
> + return false;
> +
> + val = fold_convert (r.type (), val);
I think that's wrong, it might truncate 'val'. I think we'd want
if (r.undefined_p () || !int_fits_type_p (val, r.type ()))
return false;
but then I wonder whether contains_p should have an overload
with widest_int or handle "out of bounds" values itself more gracefully?
Thanks,
Richard.
> + return r.contains_p (val);
> +}
> +
> /* Decide whether and what specialized clones of NODE should be created. */
>
> static bool
> @@ -6221,7 +6234,8 @@ decide_whether_version_node (struct cgraph_node *node)
> supports this only for integers now. */
> if (TREE_CODE (val->value) == INTEGER_CST
> && !plats->m_value_range.bottom_p ()
> - && !plats->m_value_range.m_vr.contains_p (val->value))
> + && !ipa_range_contains_p (plats->m_value_range.m_vr,
> + val->value))
> {
> /* This can happen also if a constant present in the source
> code falls outside of the range of parameter's type, so
> we
> --
> 2.40.0
>
