-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stack allocated boxes end up address exposed #104250
Comments
The If you rewrite as public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
if (value is bool b && targetType == typeof(bool))
{
return !b;
}
throw new NotSupportedException();
} you would get the expected cleanup: ; Method Program:<<Main>$>g__Test|0_0() (FullOpts)
G_M10120_IG01: ;; offset=0x0000
;; size=0 bbWeight=1 PerfScore 0.00
G_M10120_IG02: ;; offset=0x0000
xor ecx, ecx
;; size=2 bbWeight=1 PerfScore 0.25
G_M10120_IG03: ;; offset=0x0002
tail.jmp [System.Console:WriteLine(ubyte)]
;; size=6 bbWeight=1 PerfScore 2.00
; Total bytes of code: 8 |
Since the local address visitor is also now join-sensitive perhaps it would be worth trying to trim this control flow earlier. But it requires IR walks... unless, say we detect this during inlining and are able to handle things there. That is, if the inline fail reason is "no return," then add the node/stmt/etc to some worklist, and after inlining is done, we run down the list, split trees just before the calls, discard what comes after, change the block to BBJ_THROW, and trim of successor edges. Maybe. |
Definitely seems like general goodness if we can refine the control flow earlier. One alternative is to implement something like #94563 in local morph too, and track which predecessors can reach which successors. We could support these no-return calls as well as the conditional branches that are null checks/address comparisons that local morph is now able to decide. |
FWIW there are likely several other reasons why stack-allocated boxes end up getting exposed, and this generally leads to relatively poor codegen like we see in this issue (code may well end up slower overall from the prolog zeroing, though we save on heap allocation). It would be good to systematically try and improve here. |
Marking this as future, though I may try and work on it sooner. |
Description
Repro:
Codegen for
Test
(tier 1):Configuration
53a8a01
/cc: @AndyAyersMS
The text was updated successfully, but these errors were encountered: