Loop alignment: Fix loop size calculation to exclude IG's size that are marked as not aligned

[kunalspathak]

As explained in #68510 (comment), there is a scenario when setting the loop back edge that we know we cannot align a loop and removes the IGF_LOOP_ALIGN flag without fixing the igSize. That affects the loopSize calculation depending on if it was done during loop alignment adjustment or during output.

Edit:

I have added a flag IGF_REMOVED_ALIGN but commented out the usage for now. I have added an assert to see if this was
silently missed (because we would not align a loop for some heuristic reason). I will enable the usage of IGF_REMOVED_ALIGN after that.

There were test failures https://dev.azure.com/dnceng/public/_build/results?buildId=1752445&view=results so definitely we
were hitting this scenario, but it was not failing because the loop might be big enough to not align. I have figured out another
way in 3704be5 to track the information of IGs whose align flag was removed instead of
adding IGF_REMOVED_ALIGN.

#65690: In this case, we had 2 backedges of a loop that was marked for aligned. When we set the 1st backedge, we realize that it is enclosing a loop that is marked for alignment, so we unset the flag of current loop. We visit 2nd backedge and again try to unset the align flag and expect that it was not already unset. I have updated the assert using removedAlignFlag to say that either the align flag should be present, or it was present at one point and then we removed it.

#65988: We decide to not place align instruction in prolog, but we didn't remove the align flag which later causes problem. 2322a67 fixes that.

Fixes: #68510, #65690 and #65988

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As explained in #68510 (comment), there is a scenario when setting the loop back edge that we know we cannot align a loop and removes the IGF_LOOP_ALIGN flag without fixing the igSize. That affects the loopSize calculation depending on if it was done during loop alignment adjustment or during output.

I have added a flag IGF_REMOVED_ALIGN but commented out the usage for now. I have added an assert to see if this was silently missed (because we would not align a loop for some heuristic reason). I will enable the usage of IGF_REMOVED_ALIGN after that.

Fixes: #68510

Author:	kunalspathak
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[kunalspathak]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kunalspathak]

So, we have several tests that hits the assert I added for testing which means that even today, we mismatch the actual vs. expected padding because of resolution blocks being added in between the loop making bbNatLoopNum unreliable.

[kunalspathak]

@dotnet/jit-contrib , @BruceForstall