public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Update profile for haifa-sched's recovery blocks
@ 2017-07-04 10:19 Jan Hubicka
  2017-07-04 11:17 ` Alexander Monakov
  2017-07-06  4:49 ` Jeff Law
  0 siblings, 2 replies; 4+ messages in thread
From: Jan Hubicka @ 2017-07-04 10:19 UTC (permalink / raw)
  To: gcc-patches, wilson, gnu, law, vmakarov, amonakov

Hi,
this is another bug I noticed while looking into Itanium rgression.
There is no profile attached to recovery blocks in scheduler.
I made them very unlikely, but I wonder if we can do better? After all
we probably know the probability of path that will lead for speculation
to suceed?

Honza

	* haifa-sched.c (sched_create_recovery_edges): Update profile after
	creating recovery edges.
Index: haifa-sched.c
===================================================================
--- haifa-sched.c	(revision 249928)
+++ haifa-sched.c	(working copy)
@@ -8302,7 +8302,15 @@ sched_create_recovery_edges (basic_block
   else
     edge_flags = 0;
 
-  make_edge (first_bb, rec, edge_flags);
+  edge e2 = single_succ_edge (first_bb);
+  edge e = make_edge (first_bb, rec, edge_flags);
+  e->probability = profile_probability::very_unlikely ();
+  e->count = first_bb->count.apply_probability (e->probability);
+  rec->count = e->count;
+  rec->frequency = EDGE_FREQUENCY (e);
+  e2->probability = e->probability.invert ();
+  e2->count = first_bb->count - e2->count;
+
   rtx_code_label *label = block_label (second_bb);
   rtx_jump_insn *jump = emit_jump_insn_after (targetm.gen_jump (label),
 					      BB_END (rec));

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

* Re: Update profile for haifa-sched's recovery blocks
  2017-07-04 10:19 Update profile for haifa-sched's recovery blocks Jan Hubicka
@ 2017-07-04 11:17 ` Alexander Monakov
  2017-07-04 11:21   ` Jan Hubicka
  2017-07-06  4:49 ` Jeff Law
  1 sibling, 1 reply; 4+ messages in thread
From: Alexander Monakov @ 2017-07-04 11:17 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc-patches, wilson, gnu, law, vmakarov

On Tue, 4 Jul 2017, Jan Hubicka wrote:

> Hi,
> this is another bug I noticed while looking into Itanium rgression.
> There is no profile attached to recovery blocks in scheduler.
> I made them very unlikely, but I wonder if we can do better? After all
> we probably know the probability of path that will lead for speculation
> to suceed?

I don't really understand why/how that would help (after all, when doing
speculation we must have already decided that failure is very unlikely),
but to answer the last question, scheduler's estimation of speculation
success is tracked using the 'ds_t' data type - see comments regarding
'dw_t' and 'ds_t' in sched-int.h.

I think in haifa-sched.c 'todo_spec' variable in create_check_block_twin
holds the desired estimation, in sel-sched.c it's 'check_ds' in
create_speculation_check.

Alexander

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

* Re: Update profile for haifa-sched's recovery blocks
  2017-07-04 11:17 ` Alexander Monakov
@ 2017-07-04 11:21   ` Jan Hubicka
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Hubicka @ 2017-07-04 11:21 UTC (permalink / raw)
  To: Alexander Monakov; +Cc: gcc-patches, wilson, gnu, law, vmakarov

> On Tue, 4 Jul 2017, Jan Hubicka wrote:
> 
> > Hi,
> > this is another bug I noticed while looking into Itanium rgression.
> > There is no profile attached to recovery blocks in scheduler.
> > I made them very unlikely, but I wonder if we can do better? After all
> > we probably know the probability of path that will lead for speculation
> > to suceed?
> 
> I don't really understand why/how that would help (after all, when doing
> speculation we must have already decided that failure is very unlikely),
> but to answer the last question, scheduler's estimation of speculation
> success is tracked using the 'ds_t' data type - see comments regarding
> 'dw_t' and 'ds_t' in sched-int.h.

Well, the probabilities/counts controls later passes. For example if chance
for speculation to fail is 1/100 one does not want to offload the block
into cold section or agressively optimize it for size.
If failure happens only over path that is predicted to not be taken at
all during execution run (for example because it leads to abort) then
such transforms are fine.

For this to work we would need to actually track profile_probability not
just sum of values convered to reg_br_prob_base. So perhaps I will keep code
as it is and add a TODO comment.  OK?

Honza
> 
> I think in haifa-sched.c 'todo_spec' variable in create_check_block_twin
> holds the desired estimation, in sel-sched.c it's 'check_ds' in
> create_speculation_check.
> 
> Alexander

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

* Re: Update profile for haifa-sched's recovery blocks
  2017-07-04 10:19 Update profile for haifa-sched's recovery blocks Jan Hubicka
  2017-07-04 11:17 ` Alexander Monakov
@ 2017-07-06  4:49 ` Jeff Law
  1 sibling, 0 replies; 4+ messages in thread
From: Jeff Law @ 2017-07-06  4:49 UTC (permalink / raw)
  To: Jan Hubicka, gcc-patches, wilson, gnu, vmakarov, amonakov

On 07/04/2017 04:19 AM, Jan Hubicka wrote:
> Hi,
> this is another bug I noticed while looking into Itanium rgression.
> There is no profile attached to recovery blocks in scheduler.
> I made them very unlikely, but I wonder if we can do better? After all
> we probably know the probability of path that will lead for speculation
> to suceed?
I'd expect there's info around you could use to do better, but is it
worth the effort in practice?

Jeff

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

end of thread, other threads:[~2017-07-06  4:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-04 10:19 Update profile for haifa-sched's recovery blocks Jan Hubicka
2017-07-04 11:17 ` Alexander Monakov
2017-07-04 11:21   ` Jan Hubicka
2017-07-06  4:49 ` 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).