On 11/5/23 11:50, Richard Sandiford wrote:
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.
OK. Really curious if we might be able to use this to improve the
vsetvl bits in the RISC-V backend.
Jeff
