https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103188
Aldy Hernandez <aldyh at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at redhat dot com,
| |amacleod at redhat dot com
--- Comment #9 from Aldy Hernandez <aldyh at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at
>
> #666394 0x00000000015f2170 in should_duplicate_loop_header_p (
> header=<basic_block 0x7ffff654fbc8 (14)>, loop=0x7ffff66aa9f0,
> limit=0x7fffffffd97c, query=0x3fccb70)
> at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
> 83 && !entry_loop_condition_is_static (loop, query))
>
> likely ranger is confused by the intermediate IL (from other loops header
> copying), the IL is kept partly not in up-to-date SSA form (because running
> update_ssa is costly so we run it once after doing all header copying in
> a function).
Ughh, yeah. Ranger won't do well with in-flight SSA. I think we can do ok
with minimally changing IL like what evrp does with the substitute and fold
engine, but we expect things quite sane.
When working on this patch I saw the call to gimple_duplicate_sese_region would
increase the number of BBs, which caused problems in the cache and Andrew
fixed. I thought that was it for issues, obviously not.
>
> In this case we applied loop header copying to loop 4 containing loop 5
> which we are now processing.
>
> Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
> in a stmt are still old and _not_ replaced with their current definition.
> There's only so much you can do with such IL, in particular invoking SCEV
> isn't among that.
>
> You can actually check whether a SSA name may be affected by checking
> name_registered_for_update_p. SCEV doesn't do that.
Hmmm, useful.
>
> In the end that means that we'd have to do the ranger analysis before
> actually applying the header copying.
>
> Note that the current place of the
>
> /* Avoid loop header copying when optimizing for size unless we can
> determine that the loop condition is static in the first
> iteration. */
> if (optimize_loop_for_size_p (loop)
> && !loop->force_vectorize
> && !entry_loop_condition_is_static (loop, query))
> {
>
> is off in any case, since we iterate on blocks to copy, instead it should
> be done exactly once per loop. So we can do the "head", up until this
> and the very first should_duplicate_loop_header_p first for each loop,
> recording candidates in a vector and in a second loop process them all,
> not doing the already done entry_loop_condition_is_static.
>
> Let me cook up a patch to do that.
Thanks for fixing this!
