Commits on Jan 21, 2022

1. Simplify alignment block marking …

   Currently, loops that are candidates for alignment are determined
   immediately after loop recognition. The top block of these loops
   are marked by setting the `BBF_LOOP_ALIGN` flag. Later, just before
   codegen, the `placeLoopAlignInstructions` phase is called to mark
   the blocks where the actual align instructions will be placed.
   Between these two phases, the `BBF_LOOP_ALIGN` flag needs to be maintained
   through various optimization phases.
   
   We can simplify this by deferring marking the loops to align until
   we call the `placeLoopAlignInstructions` phase. Then, we don't need
   to worry about maintaining the `BBF_LOOP_ALIGN` flag. The loop table
   is still valid, so can be used. (Note that if we ever want to "kill"
   the loop table earlier in compilation, we could simply move the
   `BBF_LOOP_ALIGN` marking to that point, and still avoid all the
   flag maintenance.) This PR makes that change.
   
   To avoid too many diffs, `DEFAULT_ALIGN_LOOP_MIN_BLOCK_WEIGHT` is
   reduced from 4 to 3. This is because many loops (without profile data)
   end up with a weight of 4, and if those loops are cloned, the weight
   of the hot path gets reduced to 3.96 (so the cold path gets at least
   some non-zero weight). We still want these hot path cloned loops to
   be aligned. However, decreasing this does cause some more ASP.NET
   loops with profile data and weights between 3 and 4 to be aligned.
   
   Additionally, I added a trivial phase `optClearLoopIterInfo` to clear
   out all the loop table info related to `LPFLG_ITER`. This data is used
   by loop cloning and unrolling, but not afterwards. I still want to be
   able to dump the loop table without hitting asserts about improper
   `LPFLG_ITER` form data, and don't want downstream phases to take a dependency
   on this data, so clearing it out enables that.
   
   There are a few diffs where we align more loops even without profile
   data because the weight of loop top blocks increases due to various
   flow optimizations (like block compaction), and now we see the larger
   weight before making the alignment decision.

   

   BruceForstall committed Jan 21, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 31303a9
   • Browse repository at this point

   Copy the full SHA

   31303a9 View commit details

   Browse the repository at this point in the history