http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899

--- Comment #4 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2011-03-01 
22:13:15 UTC ---
Created attachment 23508
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23508
proposed fix

When the non-exit path is removed during the complete peeling of the loop, we
may need to move some basic blocks up the loop hierarchy (this happens when
this removal destroys the path from the bb to the latch of the considered
superloop).  We achieve this by iteratively moving blocks to the common
superloop of their successors; when a block is moved up the hierarchy, we add
its predecessors to the queue to process.  However, when the predecessor of bb
already belongs to a loop higher in the hierarchy, we do not put it to the
queue (since the change at bb obviously cannot affect the placement of the
predecessor).  This gets slightly more complicated by the need to handle
subloops; in the described heuristics, we were mistakenly comparing the
position of the predecessor with the subloop, instead of with the loop to that
the subloop was moved.

Reply via email to