mode-switching: Add a backprop hook

This patch adds a way for targets to ask that selected mode changes
be brought forward, through a combination of:

(1) requiring a mode in blocks where the entity was previously
    transparent

(2) pushing the transition at the head of a block onto incomging edges

SME has two uses for this:

- A "one-shot" entity that, for any given path of execution,
  either stays off or makes exactly one transition from off to on.
  This relies only on (1) above; see the hook description for more info.

  The main purpose of using mode-switching for this entity is to
  shrink-wrap the code that requires it.

- A second entity for which all transitions must be from known
  modes, which is enforced using a combination of (1) and (2).
  More specifically, (1) looks for edges B1->B2 for which:

  - B2 requires a specific mode and
  - B1 does not guarantee a specific starting mode

  In this system, such an edge is only possible if the entity is
  transparent in B1.  (1) then forces B1 to require some safe common
  mode.  Applying this inductively means that all incoming edges are
  from known modes.  If different edges give different starting modes,
  (2) pushes the transitions onto the edges themselves; this only
  happens if the entity is not transparent in some predecessor block.

The patch also uses the back-propagation as an excuse to do a simple
on-the-fly optimisation.

Hopefully the comments in the patch explain things a bit better.

gcc/
	* target.def (mode_switching.backprop): New hook.
	* doc/tm.texi.in (TARGET_MODE_BACKPROP): New @hook.
	* doc/tm.texi: Regenerate.
	* mode-switching.cc (struct bb_info): Add single_succ.
	(confluence_info): Add transp field.
	(single_succ_confluence_n, single_succ_transfer): New functions.
	(backprop_confluence_n, backprop_transfer): Likewise.
	(optimize_mode_switching): Use them.  Push mode transitions onto
	a block's incoming edges, if the backprop hook requires it.

0 files changed, 0 insertions, 0 deletions