Quoting discussion in dotnet/coreclr#13903:
While you're looking at this code, can you double-check what happens in minopts/debug modes? I'm not sure what the right behavior is there, come to think of it...
The code to merge down to no more than four returns originally came from a correctness restriction on x86, so it's been firing unconditonally. Before dotnet/coreclr#13792, therefore, the behavior under minopts/debug was the same as when optimizing -- to merge to one return if we have sync block etc., or if we have more than four returns. After dotnet/coreclr#13792 and continuing with this change as currently coded up, the behavior under minopts/debug is still the same as when optimizing -- merge to one return if we have sync block etc., otherwise merge down to no more than four returns, segregating constants where possible.
Arguably the minopts/debug behavior should be more like the previous behavior -- in the case that there are more than four returns, shrink down to one, regardless of whether any are constant... do you think I should make that change?
Not sure what the right behavior should be. Also this is probably a separable issue.
Offhand I'd say that in minopts/debug we should always produce one return, but it is not clear if that always gives faster jit TP / smaller code size. Also it's at odds with minopts trying to do minimal "risky" work.
I suppose you could go back and see if there is any minopts TP/size impact from your original change and then if there is we can figure out what the appropriate behavior should be.
category:implementation
theme:flowgraph
skill-level:expert
cost:medium
Quoting discussion in dotnet/coreclr#13903:
category:implementation
theme:flowgraph
skill-level:expert
cost:medium