public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: [3/3] Fix PR78120, in ifcvt/rtlanal/i386.
@ 2016-11-23 19:45 Uros Bizjak
  0 siblings, 0 replies; 3+ messages in thread
From: Uros Bizjak @ 2016-11-23 19:45 UTC (permalink / raw)
  To: gcc-patches; +Cc: Bernd Schmidt

> 3. ifcvt computes the sum of costs for the involved blocks, but only
> makes a before/after comparison when optimizing for size. When
> optimizing for speed, it uses max_seq_cost, which is an estimate
> computed from BRANCH_COST, which in turn can be zero for predictable
> branches on x86.

Can you please correct the addition below? It makes me cry thinking
that buggy function will be immortalized in the gcc testsuite...

> +static inline u128 add_u128 (u128 a, u128 b)
> +{

  a.hi += b.hi;

> +  a.lo += b.lo;
> +  if (a.lo < b.lo)
> +    a.hi++;
> +
> +  return a;

Uros.

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [0/3] Fix PR71280, in ifcvt/rtlanal/i386.
@ 2016-11-23 18:58 Bernd Schmidt
  2016-11-23 19:03 ` [3/3] Fix PR78120, " Bernd Schmidt
  0 siblings, 1 reply; 3+ messages in thread
From: Bernd Schmidt @ 2016-11-23 18:58 UTC (permalink / raw)
  To: GCC Patches

This is a small series of patches to fix various problems in cost 
calculations that together caused PR71280, a missed optimization 
opportunity.

A summary of the problems:

1. I noticed comparisons between set_src_cost and set_rtx_cost seemed to 
be invalid. There seems to be no good reason that insn_rtx_cost 
shouldn't use the latter. It also makes the numbers comparable to the
ones you get from seq_cost.

2. The i386 backend mishandles SET rtxs. If you have a fairly plain 
single-insn SET, you tend to get COSTS_N_INSNS (2) out of set_rtx_cost, 
because rtx_costs has a default of COSTS_N_INSNS (1) for a SET, and you 
get the cost of the src in addition to that.

3. ifcvt computes the sum of costs for the involved blocks, but only 
makes a before/after comparison when optimizing for size. When 
optimizing for speed, it uses max_seq_cost, which is an estimate 
computed from BRANCH_COST, which in turn can be zero for predictable 
branches on x86.

It seems a little risky to tweak costs this late in the process, but all 
of these should be improvements so it would put us on a better footing 
for fixing performance issues. I'll leave it to the reviewer to decide 
whether we want this now or after gcc-7.

The series was bootstrapped and tested on x86_64-linux. There's the 
following new guality fail:

-PASS: gcc.dg/guality/pr54693-2.c   -Os  line 21 x == 10 - i
-PASS: gcc.dg/guality/pr54693-2.c   -Os  line 21 y == 20 - 2 * i
+FAIL: gcc.dg/guality/pr54693-2.c   -Os  line 21 x == 10 - i
+FAIL: gcc.dg/guality/pr54693-2.c   -Os  line 21 y == 20 - 2 * i

which appears to be caused by loss of debuginfo in ivopts:

-  # DEBUG x => (int) ((unsigned int) x_9(D) - (unsigned int) i_14)
-  # DEBUG y => (int) ((unsigned int) y_10(D) - (unsigned int) i_14 * 2)
+  # DEBUG x => NULL
+  # DEBUG y => NULL

I'd claim this is out of scope for this patch series. So, ok?


Bernd

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-11-23 19:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-23 19:45 [3/3] Fix PR78120, in ifcvt/rtlanal/i386 Uros Bizjak
  -- strict thread matches above, loose matches on Subject: below --
2016-11-23 18:58 [0/3] Fix PR71280, " Bernd Schmidt
2016-11-23 19:03 ` [3/3] Fix PR78120, " Bernd Schmidt
2016-11-23 19:38   ` Jeff Law

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).