JIT: Make BasicBlock::bbJumpKind private #92908
Conversation
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThis is the beginning of a larger effort to disallow the use of BBJ_NONE (reserved for basic blocks that fall through) before the current method's block layout is finalized. @AndyAyersMS PTAL, cc @dotnet/jit-contrib
|
|
|
||
| void setBBJumpKind(BBjumpKinds kind DEBUG_ARG(Compiler* comp)) | ||
| { | ||
| #ifdef DEBUG |
There was a problem hiding this comment.
I'm probably getting ahead of myself here, but I'm thinking we will need to track whether BBJ_NONE is allowed or not in the current Compiler's state, so passing in a pointer to it will enable us to assert this state. I avoided making this a noway_assert to minimize TP diffs, and made comp a debug arg to avoid unused variable warnings in Release builds (though this approach also has the negative effect of removing this assert in Checked builds).
There was a problem hiding this comment.
I would personally recommend using a verifier pattern (i. e. adding an assert somewhere in fgdiagnostic.cpp) for checking this property instead of the setters. It will make for less debug-only code overall.
There was a problem hiding this comment.
I like the cleanliness of your suggestion, but if we move this check to somewhere like Compiler::fgDebugCheckBBlist instead of checking every time bbJumpKind is updated, then is there any need to make bbJumpKind private? @AndyAyersMS
There was a problem hiding this comment.
is there any need to make bbJumpKind private
Not strictly, but it is still an improvement.
https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/clr-jit-coding-conventions.md
15.5.1 Public data members
Do not declare public data members. Instead, public accessor functions should be exposed to access class members.
There was a problem hiding this comment.
Yes, please keep this field private.
Eventually we will probably do more work when the jump kind gets changed -- for instance calling add/remove ref on the appropriate blocks.
So having the extra comp argument here is also fine by me, it will prove useful down the road.
src/coreclr/jit/assertionprop.cpp
Outdated
| @@ -5260,7 +5260,7 @@ class AssertionPropFlowCallback | |||
| { | |||
| ASSERT_TP pAssertionOut; | |||
|
|
|||
| if (predBlock->bbJumpKind == BBJ_COND && (predBlock->bbJumpDest == block)) | |||
| if (predBlock->getBBJumpKind() == BBJ_COND && (predBlock->bbJumpDest == block)) | |||
There was a problem hiding this comment.
Looks like most uses can be replaced with an existing block->KindIs(...) (it also supports 'params').
Also, should it be Get or get?
There was a problem hiding this comment.
Thank you for catching that -- I'll push a revision converting all the bbJumpKind comparisons to KindIs().
I'm not sure what the case should be. Some BasicBlock methods (like KindIs) use Pascal case, while others (like makeBlockHot) use camel case.
There was a problem hiding this comment.
The convention for all new code in the Jit is to use PascalCase, except in LSRA (where camelCase is used consistently).
|
SPMI replay error is infrastructure related: so maybe retry this bit? |
|
Looks like the infrastructure issue didn't repro; CI is clean now. |
ghost
locked as resolved and limited conversation to collaborators
This is the beginning of a larger effort to disallow the use of BBJ_NONE (reserved for basic blocks that fall through) before the current method's block layout is finalized.
@AndyAyersMS PTAL, cc @dotnet/jit-contrib