Consider finally that jumps to itself as non-empty #58771
Conversation
ghost
added
the
area-CodeGen-coreclr
|
@dotnet/jit-contrib |
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsWe were assuming that if a As such, after removing Fixes: #58729
|
|
I think we should fix this by classifying finallies that |
Ah, ok. So will that remove the block inside finally in later phase (dead code) or it will never remove the block and we will go ahead and generate code except that we will not go to it? |
|
I suspect it will stay around... as mentioned over in the issue the code in the finally is reachable if there's an exception thrown in the try. So it's not actually dead. |
kunalspathak
changed the title
|
@AndyAyersMS - can you take another look? |
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1217938294 |
|
Isn't the issue that there is the code is looking for |
|
I think the checks are equivalent, but yeah the comment I put there is not describing what the code does. |
ghost
locked as resolved and limited conversation to collaborators
3 participants
We were assuming that if a
finallyis empty, it doesn't have any blocks pointing to it, but sometimes Roslyn would have a copy of code insidefinallyinto a block that followsfinallyblock, and directly jump to that block.As such, after removing
CALL_FINALLYblock, the block insidefinallycan jump back to itself and hence one additional reference. As such, while removing empty finally, we should just decrease the reference count of finally block by 1 and then letfgRemoveBlock()take care of further reducing the reference count, if there exist one.Fixes: #58729