Assertion failed 'markedLastLoop && markedCurrLoop' during 'Generate code'

[kunalspathak]

Started seeing these lately in superpmi-replay pipelines

e.g.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1072803&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=2694d93b-a574-5310-1876-2e252085b877
https://dev.azure.com/dnceng-public/public/_build/results?buildId=1072803&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=2694d93b-a574-5310-1876-2e252085b877

Known Issue Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[dotnet-policy-service]

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

[kunalspathak]

It is a manifestation of similar problem that I fixed in #114882. Here, we have something like:

IG60:

    align for IG71


IG71:
    nop   ; nop inserted after IG that had GC capable call

IG72:
   ...
   loop IG72

IG82:
    ...
    loop IG82


IG89:
   ...
   jump IG72

Basically, IG72 loop encloses IG82 loop and hence we try to disable loop alignment for it. When we try to get loop head IG, since nop was inserted in IG71, the loop head returned is IG72, but the align instruction (from IG60) that we look up to find the original loop head still points to IG71. Since there is a mismatch, we fail to disable loop alignment for IG72 loop.

#114882 fixes the problem if we have already seen the IG in question and just go ahead and update the new IG for preHead. In this case, we didn't even yet seen the IG that contains loop (IG72) and hence fail to update it.