Diff in checked vs. release

[kunalspathak]

Call to GetSwitchDescMap() that creates m_switchDescMap if it is nullptr. m_switchDescMap is invalidated everytime we renumber blocks or we replace jump targets. However, if I trace the caller of GetSwitchDescMap(), I see that it can get called from DEBUG via fgDebugCheckProfileWeights() and repopulate the map, which will behave differently at later point of time when we UpdateSwitchTableTarget().

runtime/src/coreclr/jit/fgflow.cpp

Lines 627 to 630 in 703f6e8

	if (m_switchDescMap == nullptr)
	{
	return; // No mappings, nothing to do.
	}

In Debug, map != nullptr and hence we update the target, but in Release, it is still nullptr. In Debug, since we updated the target, it changes the successors we visit and variables created, offsets they get assigned to, etc.

Mostly caused by #98526

[ghost]

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

Issue Details

---

Call to GetSwitchDescMap() that creates m_switchDescMap if it is nullptr. m_switchDescMap is invalidated everytime we renumber blocks or we replace jump targets. However, if I trace the caller of GetSwitchDescMap(), I see that it can get called from DEBUG via fgDebugCheckProfileWeights() and repopulate the map, which will behave differently at later point of time when we UpdateSwitchTableTarget().

runtime/src/coreclr/jit/fgflow.cpp

Lines 627 to 630 in 703f6e8

	if (m_switchDescMap == nullptr)
	{
	return; // No mappings, nothing to do.
	}

In Debug, map != nullptr and hence we update the target, but in Release, it is still nullptr. In Debug, since we updated the target, it changes the successors we visit and variables created, offsets they get assigned to, etc.

Mostly caused by #98526

Author:	kunalspathak
Assignees:	amanasifkhalid
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-