Assertion failed 'block->lastNode()->OperGet() == GT_RETFILT' during 'Generate code' (IL size 1480; hash 0x46e9aa75; FullOpts) #85088

Activity

1. kunalspathak

   added

   arch-x86

   os-windows

   area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMICLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

   on Apr 20, 2023
2. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Apr 20, 2023
4. kunalspathak commented on Apr 20, 2023

   

   kunalspathak

   on Apr 20, 2023

   ContributorAuthor

   More actions

   @BruceForstall - Can this be related to your recent refactoring work?
5. BruceForstall

   self-assigned this

   on Apr 20, 2023
6. BruceForstall

   added this to the 8.0.0 milestone on Apr 20, 2023
7. ghost removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Apr 20, 2023
8. BruceForstall commented on Apr 20, 2023

   

   BruceForstall

   on Apr 20, 2023

   Contributor

   More actions

   @BruceForstall - Can this be related to your recent refactoring work?

   Unknown, but I'll take a look
9. BruceForstall commented on Apr 25, 2023

   

   BruceForstall

   on Apr 25, 2023

   Contributor

   More actions

   This doesn't fail in the current main, but does fail with a tree from several days ago (e.g., 3713168). I'm assuming that some recent JIT change perturbed the IR but didn't actually fix the issue.
10. BruceForstall commented on Apr 26, 2023

    

    BruceForstall

    on Apr 26, 2023

    Contributor

    More actions

    @jakobbotsch This is due to physical promotion. I didn't know physical promotion was part of our usual stress mix at this point; is that appropriate?

    On x86, GT_RETFILT must be the last operation of a filter/finally return. But it appears physical promotion inserts a "read back" after the RETFILT node:

    *** NYI: Conservatively marked as read-back
    STMT00096 ( 0x344[E-] ... 0x344 )
                   [000568] -----------                         *  RETFILT   void
    Reading back replacement V11.[000..004) -> V98 at the end of BB35
    

    Note; the IR dump after the phase is:

    ***** BB35
    STMT00096 ( 0x344[E-] ... 0x344 )
                   [000568] -----------                         *  RETFILT   void
    
    ***** BB35
    STMT00191 ( ??? ... ??? )
                   [001190] -A---------                         *  ASG       int
                   [001188] D------N---                         +--*  LCL_VAR   int    V98 tmp78
                   [001189] -----------                         \--*  LCL_FLD   int    V11 loc10        [+0]
    

    but the STMT00191 and [001190] and related nodes do not appear in the dump before this location. It would be helpful to dump them when they are created so it's more obvious to see who is creating them and why.

    As mentioned above, this doesn't fail in main. Has it been intentionally fixed, or did IR perturbations make it "go away"?
11. BruceForstall

    assigned

    jakobbotsch

    and unassigned

    BruceForstall

    on Apr 26, 2023
12. jakobbotsch commented on Apr 26, 2023

    

    jakobbotsch

    on Apr 26, 2023

    Member

    More actions

    @jakobbotsch This is due to physical promotion. I didn't know physical promotion was part of our usual stress mix at this point; is that appropriate?

    It is meant to be fully functional (but maybe not profitable), so I'd say so.

    On x86, GT_RETFILT must be the last operation of a filter/finally return. But it appears physical promotion inserts a "read back" after the RETFILT node:

    *** NYI: Conservatively marked as read-back
    STMT00096 ( 0x344[E-] ... 0x344 )
                   [000568] -----------                         *  RETFILT   void
    Reading back replacement V11.[000..004) -> V98 at the end of BB35
    

    Note; the IR dump after the phase is:

    ***** BB35
    STMT00096 ( 0x344[E-] ... 0x344 )
                   [000568] -----------                         *  RETFILT   void
    
    ***** BB35
    STMT00191 ( ??? ... ??? )
                   [001190] -A---------                         *  ASG       int
                   [001188] D------N---                         +--*  LCL_VAR   int    V98 tmp78
                   [001189] -----------                         \--*  LCL_FLD   int    V11 loc10        [+0]
    

    but the STMT00191 and [001190] and related nodes do not appear in the dump before this location. It would be helpful to dump them when they are created so it's more obvious to see who is creating them and why.

    Makes sense, I will make sure to dump these when they are created. FWIW, physical promotion just uses fgInsertStmtNearEnd, so it seems that helper is lacking handling for these blocks. I'll fix it.

    As mentioned above, this doesn't fail in main. Has it been intentionally fixed, or did IR perturbations make it "go away"?

    #85105 may have altered the IR as a side effect.
13. jakobbotsch

    added a commit that references this issue on Apr 26, 2023

    JIT: Handle GT_RETFILT in fgInsertStmtNearEnd

    ...

    This issue will close once commit 1b47e21 is merged into the 'main' branch.

    1b47e21
14. ghost added

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Apr 26, 2023
15. jakobbotsch

    closed this as completedin #85420on Apr 27, 2023
16. jakobbotsch

    added a commit that references this issue on Apr 27, 2023

    JIT: Handle GT_RETFILT in fgInsertStmtNearEnd (#85420)

    ...

    This issue will close once commit a08818e is merged into the 'main' branch.

    a08818e
17. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Apr 27, 2023
18. ghost locked as resolved and limited conversation to collaborators on May 27, 2023