On 9/3/21 5:04 PM, Jeff Law wrote:
On 9/3/2021 7:57 AM, Aldy Hernandez wrote:
The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument. When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE. This
may not necessarily be true in the future, if the backward threader is
called from another context. This patch removes the default definition,
in favor of an argument that is exactly the same as the identically
named function in tree-ssa-threadupdate.c. I think this also makes it
less confusing when looking at both methods across the source base.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
* tree-ssa-threadbackward.c
(back_threader::thread_through_all_blocks):
(back_threader_registry::thread_through_all_blocks):
(try_thread_blocks):
(pass_early_thread_jumps::execute):
Presumably this is preparing for addressing some of the issues we
discussed via email a little while ago -- ie to avoid having the
backwards threader mucking up loops and allowing the loop optimizer to
make more decisions about things like peeling because the loop optimizer
has a cost model for this stuff whereas the jump threaders to not.
Yes.
Currently the forward and the backward threaders have different
profitability models. The backward threader has one function to control
it all, whereas the forward threader has ad-hoc code sprinkled
throughout. I would like to combine both models, though I'm not sure
whether I'll be able to get everything done in this release.
Also, both threaders have different block duplication code. The forward
threader's seems more permissive than the other, so this should also be
combined. See for instance, EDGE_FSM_THREAD versus EDGE_*BLOCK.
Right now I'm trying to replace the forward threader with an enhanced
version of the current backward threader, and I'm running into issues
because the backward threader is handcuffed as to what it can do (see
profitable_path_p). It will take some untangling to figure out what to
allow it to do, without it going ape-shit and threading iterations of
loops, etc.
Anywhoo...it's a work in progress. I have upcoming patches to both the
forward threader clients (to rid them of their dependence on VRP/evrp),
and to the backward threader to enhance it further so it can get pretty
much everything the forward threader currently gets.
Gawwwd, this is so convoluted. I hope most of it made sense.
Aldy
