https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Component|middle-end |tree-optimization
Ever confirmed|0 |1
CC| |rguenth at gcc dot gnu.org
Last reconfirmed| |2020-10-07
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's because we hit
/* If this is a load then do not sink past any stores.
??? This is overly simple but cheap. We basically look
for an existing load with the same VUSE in the path to one
of the sink candidate blocks and we adjust commondom to the
nearest to commondom. */
if (gimple_vuse (stmt))
{
...
imm_use_iterator imm_iter;
use_operand_p use_p;
basic_block found = NULL;
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (stmt))
{
gimple *use_stmt = USE_STMT (use_p);
basic_block bb = gimple_bb (use_stmt);
/* For PHI nodes the block we know sth about
is the incoming block with the use. */
if (gimple_code (use_stmt) == GIMPLE_PHI)
bb = EDGE_PRED (bb, PHI_ARG_INDEX_FROM_USE (use_p))->src;
/* Any dominator of commondom would be ok with
adjusting commondom to that block. */
bb = nearest_common_dominator (CDI_DOMINATORS, bb, commondom);
if (!found)
found = bb;
where we do not ignore stmt itself (nor stmts in its same block). We also
do not ignore the function return which directs us to BB2 as well. The
heuristic looks quite misguided to me ...
