Message ID | 20230424074332.141890-1-aldyh@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D4755385840A for <patchwork@sourceware.org>; Mon, 24 Apr 2023 07:44:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4755385840A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682322248; bh=ZI/fDuDwvCQ3FrPD05dLjzmtQqRTSz06Ec2J+xN0JY4=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=YSQJUntbfn3UZ/JzKdPqojapK3Rgwglqq7neGzuQfiQLc8HhEQ703Dnt+BhGa7ziT KlT9S9flg+dEC6fdPjrs5tcfxgTHV5304RE8R2aK1TPGbo1/pWy840e3MtCnBopMR+ wPb6CTRUBLZ1jmiS2G0ojT2VelkSctVOiWCNt3+w= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B0BAA3858D32 for <gcc-patches@gcc.gnu.org>; Mon, 24 Apr 2023 07:43:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0BAA3858D32 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-556-6ZEOvs0wOMacApCs5v9VYw-1; Mon, 24 Apr 2023 03:43:39 -0400 X-MC-Unique: 6ZEOvs0wOMacApCs5v9VYw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8EAA6800047 for <gcc-patches@gcc.gnu.org>; Mon, 24 Apr 2023 07:43:39 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 35DDE492B03; Mon, 24 Apr 2023 07:43:39 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.17.1/8.17.1) with ESMTPS id 33O7haUC141918 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 24 Apr 2023 09:43:37 +0200 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 33O7hafB141917; Mon, 24 Apr 2023 09:43:36 +0200 To: GCC patches <gcc-patches@gcc.gnu.org> Cc: Andrew MacLeod <amacleod@redhat.com>, Aldy Hernandez <aldyh@redhat.com> Subject: [PATCH] Pass correct type to irange::contains_p() in ipa-cp.cc. Date: Mon, 24 Apr 2023 09:43:32 +0200 Message-Id: <20230424074332.141890-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Aldy Hernandez <aldyh@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Pass correct type to irange::contains_p() in ipa-cp.cc.
|
|
Commit Message
Aldy Hernandez
April 24, 2023, 7:43 a.m. UTC
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(-)
Comments
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 >
On 4/24/23 10:30, Richard Biener wrote: > 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; This won't work for pointers. Is there a suitable version that handles pointers as well? > > but then I wonder whether contains_p should have an overload > with widest_int or handle "out of bounds" values itself more gracefully? Only IPA is currently passing incompatible types to contains_p(), so I'd prefer to keep things stricter until there is an actual need for them. Thanks. Aldy
On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On 4/24/23 10:30, Richard Biener wrote: > > 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; > > This won't work for pointers. Is there a suitable version that handles > pointers as well? Where does it not work? And when do you get pointer values/types where they mismatch sufficiently (how?) to make ranger unhappy? > > > > but then I wonder whether contains_p should have an overload > > with widest_int or handle "out of bounds" values itself more gracefully? > > Only IPA is currently passing incompatible types to contains_p(), so I'd > prefer to keep things stricter until there is an actual need for them. > > Thanks. > Aldy >
On 4/24/23 14:10, Richard Biener wrote: > On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <aldyh@redhat.com> wrote: >> >> >> >> On 4/24/23 10:30, Richard Biener wrote: >>> 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; >> >> This won't work for pointers. Is there a suitable version that handles >> pointers as well? > > Where does it not work? And when do you get pointer values/types > where they mismatch sufficiently (how?) to make ranger unhappy? > It's not ranger that's unhappy, this is just irange::contains_p(). IPA works on both integers and pointers, and pointers don't have TYPE_MIN/MAX_VALUE defined, so we ICE in int_fits_type_p: type_low_bound = TYPE_MIN_VALUE (type); type_high_bound = TYPE_MAX_VALUE (type);
On Mon, Apr 24, 2023 at 2:32 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On 4/24/23 14:10, Richard Biener wrote: > > On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <aldyh@redhat.com> wrote: > >> > >> > >> > >> On 4/24/23 10:30, Richard Biener wrote: > >>> 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; > >> > >> This won't work for pointers. Is there a suitable version that handles > >> pointers as well? > > > > Where does it not work? And when do you get pointer values/types > > where they mismatch sufficiently (how?) to make ranger unhappy? > > > > It's not ranger that's unhappy, this is just irange::contains_p(). > > IPA works on both integers and pointers, and pointers don't have > TYPE_MIN/MAX_VALUE defined, so we ICE in int_fits_type_p: > > type_low_bound = TYPE_MIN_VALUE (type); > type_high_bound = TYPE_MAX_VALUE (type); Ah. The code handles NULL TYPE_MIN/MAX_VALUE just fine so I wonder if it works to change the above to type_low_bound = INTEGRAL_TYPE_P (type) ? TYPE_MIN_VALUE (type) : NULL_TREE; ... alternatively you could use wi::fits_to_tree_p (wi::to_wide (val), type) from the IPA code. Richard.
On 4/24/23 14:35, Richard Biener wrote: > On Mon, Apr 24, 2023 at 2:32 PM Aldy Hernandez <aldyh@redhat.com> wrote: >> >> >> >> On 4/24/23 14:10, Richard Biener wrote: >>> On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <aldyh@redhat.com> wrote: >>>> >>>> >>>> >>>> On 4/24/23 10:30, Richard Biener wrote: >>>>> 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; >>>> >>>> This won't work for pointers. Is there a suitable version that handles >>>> pointers as well? >>> >>> Where does it not work? And when do you get pointer values/types >>> where they mismatch sufficiently (how?) to make ranger unhappy? >>> >> >> It's not ranger that's unhappy, this is just irange::contains_p(). >> >> IPA works on both integers and pointers, and pointers don't have >> TYPE_MIN/MAX_VALUE defined, so we ICE in int_fits_type_p: >> >> type_low_bound = TYPE_MIN_VALUE (type); >> type_high_bound = TYPE_MAX_VALUE (type); > > Ah. The code handles NULL TYPE_MIN/MAX_VALUE just fine so > I wonder if it works to change the above to > > type_low_bound = INTEGRAL_TYPE_P (type) ? TYPE_MIN_VALUE (type) : NULL_TREE; > ... > > alternatively you could use wi::fits_to_tree_p (wi::to_wide (val), > type) from the IPA code. That works. How's this? Tested on x86-64 Linux. p.s. Once we convert the API to wide_int's (upcoming patches), I can move this logic into irange::contains_p (tree) virtual instead of ipa_range_contains_p. We'll also have an irange::contains_p (const wide_int &) which we can upgrade to a widest_int overload if need be.
On Mon, Apr 24, 2023 at 7:17 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On 4/24/23 14:35, Richard Biener wrote: > > On Mon, Apr 24, 2023 at 2:32 PM Aldy Hernandez <aldyh@redhat.com> wrote: > >> > >> > >> > >> On 4/24/23 14:10, Richard Biener wrote: > >>> On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <aldyh@redhat.com> wrote: > >>>> > >>>> > >>>> > >>>> On 4/24/23 10:30, Richard Biener wrote: > >>>>> 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; > >>>> > >>>> This won't work for pointers. Is there a suitable version that handles > >>>> pointers as well? > >>> > >>> Where does it not work? And when do you get pointer values/types > >>> where they mismatch sufficiently (how?) to make ranger unhappy? > >>> > >> > >> It's not ranger that's unhappy, this is just irange::contains_p(). > >> > >> IPA works on both integers and pointers, and pointers don't have > >> TYPE_MIN/MAX_VALUE defined, so we ICE in int_fits_type_p: > >> > >> type_low_bound = TYPE_MIN_VALUE (type); > >> type_high_bound = TYPE_MAX_VALUE (type); > > > > Ah. The code handles NULL TYPE_MIN/MAX_VALUE just fine so > > I wonder if it works to change the above to > > > > type_low_bound = INTEGRAL_TYPE_P (type) ? TYPE_MIN_VALUE (type) : NULL_TREE; > > ... > > > > alternatively you could use wi::fits_to_tree_p (wi::to_wide (val), > > type) from the IPA code. > > That works. > > How's this? Tested on x86-64 Linux. LGTM. > p.s. Once we convert the API to wide_int's (upcoming patches), I can > move this logic into irange::contains_p (tree) virtual instead of > ipa_range_contains_p. We'll also have an irange::contains_p (const > wide_int &) which we can upgrade to a widest_int overload if need be.
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); + 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