--
> > > > Sender:Jakub Jelinek
> > > > Sent At:2019 Apr. 17 (Wed.) 19:27
> > > > Recipient:Bin.Cheng
> > > > Cc:bin.cheng ; GCC Patches
> > > >
> > > > Subject:Re: [PATCH PR90078]Capping comp_cost computation in ivopts
>
gt; > Recipient:Bin.Cheng
> > > Cc:bin.cheng ; GCC Patches
> > >
> > > Subject:Re: [PATCH PR90078]Capping comp_cost computation in ivopts
> > >
> > >
> > > On Wed, Apr 17, 2019 at 07:14:05PM +0800, Bin.Cheng wrote:
> > > > >
On Sun, May 5, 2019 at 8:03 AM bin.cheng wrote:
>
> > --
> > Sender:Jakub Jelinek
> > Sent At:2019 Apr. 17 (Wed.) 19:27
> > Recipient:Bin.Cheng
> > Cc:bin.cheng ; GCC Patches
> >
> >
> --
> Sender:Jakub Jelinek
> Sent At:2019 Apr. 17 (Wed.) 19:27
> Recipient:Bin.Cheng
> Cc:bin.cheng ; GCC Patches
>
> Subject:Re: [PATCH PR90078]Capping comp_cost computation in ivopts
>
>
> On W
On Wed, Apr 17, 2019 at 07:14:05PM +0800, Bin.Cheng wrote:
> > As
> > #define INFTY 1000
> > 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.
> It's a
On Wed, Apr 17, 2019 at 3:10 PM Jakub Jelinek wrote:
>
> 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
>
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
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 cap
