From: Jakub Jelinek <jakub@redhat.com>
To: "bin.cheng" <bin.cheng@linux.alibaba.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH PR90078]Capping comp_cost computation in ivopts
Date: Wed, 17 Apr 2019 07:19:00 -0000 [thread overview]
Message-ID: <20190417071001.GR21066@tucnak> (raw)
In-Reply-To: <7cb22a67-89e5-45d3-aef4-398311416140.bin.cheng@linux.alibaba.com>
On Wed, Apr 17, 2019 at 02:13:12PM +0800, bin.cheng wrote:
> Hi,
> As discussed in PR90078, this patch checks possible infinite_cost overflow in ivopts.
> Also as discussed, overflow happens mostly because of cost scaling wrto bb_freq/loop_freq.
> For the moment, we only implement capping in comp_cost operators, while in next
> stage1, we may instead implement capping in get_scaled_computation_cost_at with
> more supporting benchmark data.
>
> BTW, I think switching costs around comparison between infinite_cost is unnecessary
> since there will be no overflow in integer after capping with infinite_cost.
>
> Bootstrap and test on x86_64, is it OK?
>
> Thanks,
> bin
>
> 2019-04-17 Bin Cheng <bin.cheng@linux.alibaba.com>
>
> PR tree-optimization/92078
> * tree-ssa-loop-ivopts.c (comp_cost::operator +,-,+=,-+,/=,*=): Add
> checks for infinite_cost overflow.
>
> 2018-04-17 Bin Cheng <bin.cheng@linux.alibaba.com>
>
> PR tree-optimization/92078
> * gcc/testsuite/g++.dg/tree-ssa/pr90078.C: New test.
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -243,6 +243,9 @@ operator+ (comp_cost cost1, comp_cost cost2)
if (cost1.infinite_cost_p () || cost2.infinite_cost_p ())
return infinite_cost;
+ if (cost1.cost + cost2.cost >= infinite_cost.cost)
+ return infinite_cost;
As
#define INFTY 10000000
what is the reason to keep the previous condition as well?
I mean, if cost1.cost == INFTY or cost2.cost == INFTY,
cost1.cost + cost2.cost >= INFTY too.
Unless costs can go negative.
@@ -256,6 +259,8 @@ operator- (comp_cost cost1, comp_cost cost2)
return infinite_cost;
gcc_assert (!cost2.infinite_cost_p ());
+ if (cost1.cost - cost2.cost >= infinite_cost.cost)
+ return infinite_cost;
Unless costs can be negative, when you first bail out
for cost1.cost == INFTY, then cost1.cost - cost2.cost won't
be INFTY (but could get negative). So shouldn't there be a guard against
that instead? Or, if costs can be negative, shouldn't there be also
guards that it doesn't grow too negative (say smaller than -INFTY)?
Jakub
next prev parent reply other threads:[~2019-04-17 7:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 7:00 bin.cheng
2019-04-17 7:19 ` Jakub Jelinek [this message]
2019-04-17 11:14 ` Bin.Cheng
2019-04-17 11:35 ` Jakub Jelinek
2019-05-05 6:02 ` bin.cheng
2019-05-06 10:11 ` Richard Biener
2019-05-06 10:24 ` Bin.Cheng
2019-05-06 10:27 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190417071001.GR21066@tucnak \
--to=jakub@redhat.com \
--cc=bin.cheng@linux.alibaba.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).