JIT: Make BasicBlock jump target private

[amanasifkhalid]

Next step for #93020. CC @dotnet/jit-contrib.

[ghost]

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

Issue Details

---

Next step for #93020. CC @dotnet/jit-contrib.

Author:	amanasifkhalid
Assignees:	amanasifkhalid
Labels:	area-CodeGen-coreclr
Milestone:	-

[amanasifkhalid]

I wanted to take these new methods as an opportunity to assert we are accessing the jump target correctly. For example, we should only read bbJumpDest if bbJumpKind is valid, and bbJumpDest should not be null for such blocks (and if we can assert bbJumpDest is only accessed when bbJumpKind is valid, then perhaps there's no need to set bbJumpDest to null when setting bbJumpKind to something like BBJ_NONE). However, these asserts turned out to be overly aggressive -- we seem to have some edge cases in a couple of phases that break these assumptions. For one, we do set and compare bbJumpDest to null in a few places, and checking if the jump kind is valid instead of null-checking bbJumpDest would probably hurt TP (as we would have to compare bbJumpKind to multiple possible valid values, versus just one null check). Would it be worth trying to strengthen our bbJumpKind/bbJumpDest abstraction if it comes at the cost of TP?

[BruceForstall]

As a next step, this could have an assert for those kinds where bbJumpDest is legal:

assert(KindIs(BBJ_CALLFINALLY,BBJ_ALWAYS,BBJ_EHCATCHRET,BBJ_LEAVE,BBJ_COND));

[amanasifkhalid]

I wanted to include that too, but this proved to be overly aggressive in a few spots. For example, in Compiler::fgFindBlockILOffset(), we check curr's bbJumpDest as long as it's not a switch statement. I could check if curr's jump kind is valid first to satisfy the assert in GetJumpDest(), but I'm not sure what our stance is on reducing TP to satisfy this constraint.

[BruceForstall]

maybe the same assert here, which would assume the bbJumpKind is set before changing/setting the bbJumpDest.

[BruceForstall]

Same assert here.

I wonder if we should treat switch and non-switch more uniformly. i.e., JumpsTo might imply any flow graph control transfer, including switches. Maybe we'll evolve this over time.

[amanasifkhalid]

Asserting bbJumpKind is valid proved to be too aggressive in JumpsTo(), as well. Should I try enabling these asserts in a follow-up PR? I think that refactor will be nontrivial, since we null-check bbJumpDest for non-jump blocks in a bunch of places.

[BruceForstall]

A follow-up PR to add asserts is fine.

[AndyAyersMS]

It seems odd that SetJumpKind has a Compiler* arg but SetJumpKindAndTarget doesn't. I would expect the latter to be a logical superset.

If you added a Compiler* arg you could then fix the switch version to allocate the BBswtDesc automatically, perhaps.

[BruceForstall]

Also assert(KindIs(BBJ_SWITCH)); here?

[amanasifkhalid]

I thought about this, but we have several instances where we set bbJumpSwt before updating bbJumpKind, and I wouldn't want to enforce an order of the function calls -- though maybe that means we should have a function for converting the block to BBJ_SWITCH that updates bbJumpKind and bbJumpSwt simultaneously?

[BruceForstall]

we should have a function for converting the block to BBJ_SWITCH that updates bbJumpKind and bbJumpSwt simultaneously?

Maybe an overloaded:

SetKindAndTarget(BBjumpKinds kind, BasicBlock* target) => set bbJumpKind/bbJumpDest
SetKindAndTarget(BBjumpKinds kind, BBswtDesc* target) => set bbJumpKind/bbJumpSwt

for those cases where both are being set?

[amanasifkhalid]

Sure thing, I'll add that in.

[BruceForstall]

You could imagine that BBJ_COND could have, here, struct { BasicBlock* bbJumpTrue; BasicBlock* bbJumpFalse; } where the true case would currently map to bbJumpDest and the false case to bbNext. And have accessors for each. Maybe that's where this will evolve?

[amanasifkhalid]

I think that's Andy's plan. He mentions in #93020 adding an explicit fall-through successor pointer to BasicBlock that would apply to BBJ_ALWAYS, BBJ_COND, etc. Would it be worth including that work in this PR, or save it for the next one? That change will probably introduce some TP diffs...

[AndyAyersMS]

Let's hold off... where I'd really like to get to is that these references are either:

• some kind of BasicBlockReference holder struct (so reassignment updates ref counts automagically); or even better, perhaps:
• FlowEdge(s)

The appeal of BasicBlockReference is that someday perhaps I'd like to be able to enumerate all the things that refer a block, including "external" BasicBlock references as well (references from the EH table, from SSA defs, special block references from the compiler object (fgFirstBB, etc), etc).

We could then eliminate all the fussing about with bbRefCounts and either have them maintained automatically or recomputed when needed.

The appeal of FlowEdges is that it simplifies some of the forward likelihood analysis, currently to find an edge to a successor you need to find the successor block and then enumerate the predecessor edges.

But not sure I want to do any of this just yet.

[SingleAccretion]

While we are discussing successor edges, I'd like to bring up the fact there is duplication between IR control flow nodes such as SWITCH/JTRUE and the block kinds. In some systems, information about successors is determined purely from the IR and "terminator" nodes.

It is an appealing system from the orthogonality/elegance perspective since there is no duplication, but it is unlikely to be suitable for us due to the throughput cost (of at least two additional indirections in HIR).

[Wraith2]

At first glace i wasn't certain what JumpsTo(block) was doing, it could be getting or setting, reading the original made it clear. Consider using IsJumpTo which would make it clearer.

[BruceForstall]

I would object to IsJumpsTo() -- that just doesn't read well. If consensus is that JumpsTo() is confusing, I'd recommend leaving these cases as block->JumpTarget() == block2

[AndyAyersMS]

I would actually prefer something like HasJumpTo since JumpsTo to me reads like there's no other option (that is, BBJ_ALWAYS) and the "has" makes it clearer this is a predicate.

[Wraith2]

Either HasJumpTo or JumpTarget() == block2 sound ok to me.

[amanasifkhalid]

I changed JumpsTo to HasJumpTo, and kept JumpsToNext the same since it indicates whether a block will always "jump" to bbNext regardless of its condition.

[amanasifkhalid]

So asserting KindIs(BBJ_SWITCH) in BasicBlock::GetJumpSwt() seems to be overly aggressive, too. This assert hits while building SPC.dll.

[AndyAyersMS]

I like to see a PR with these sorts of mechanical changes without changing behavior, and then see behavioral changes as separate follow-ups. There are so many diffs here with renaming that it is easy to miss something that changes things more fundamentally.

In practice you may find you need to do both at the same time to figure out which mechanical changes you want, but you can either keep separate commits locally and PR them one by one, or (more painful) split a commit up to defer the behavior changing parts.

[amanasifkhalid]

@AndyAyersMS @BruceForstall PTAL. Per Bruce's suggestion, I added a helper method for simultaneously updating the jump kind and target, and asserting that the jump kind argument is valid (BBJ_ALWAYS, BBJ_COND, etc) doesn't seem to break any of our current invariants.

Since we probably want to ensure bbJumpDest is read only when a block contains a jump, I'd like your opinion about how to handle the instances where we currently set/compare bbJumpDest to null. For example, when we first initialize a block, we set its jump kind in bbNewBasicBlock, but not its jump target, so it is possible for a block with a jump to have a null jump target for a period of time after its creation. Also, when converting a block's jump kind to BBJ_NONE, we sometimes set its jump target to null, and other times leave it be under the assumption we won't be reading it. Then, there are plenty of asserts where we compare the block's jump target to null -- we either assert a block with a valid jump kind doesn't have a null target, or a block with an invalid jump kind does have a null target. And as a quick way to check if a block has a jump, we sometimes check if its jump target is not null in conditions.

I imagine checking if the jump target is null is cheaper (in terms of TP) than checking if the jump kind is valid, since we'd have to check against multiple jump kinds each time. So maybe it's beneficial to allow bbJumpDest to be nullable, but then we cannot ensure bbJumpDest is read only for blocks with valid jump kinds, which limits our ability to do the asserts Bruce suggested above. Maybe we could standardize setting bbJumpDest to null when setting bbJumpKind to a non-jump kind, and then add a helper method like HasJump() that simply checks if bbJumpDest is null (and asserts bbJumpKind is consistent with whether bbJumpDest is null or not)? This would replace calls like HasJumpTo(nullptr) and remove calls like SetJumpDest(nullptr), allowing us to assert those methods are called only for blocks with valid jump kinds. As for new blocks with a valid jump kind and no jump target yet, I don't think we are reading their (null) jump target until it is set anyway, so we can similarly assert that GetJumpDest() is only called on blocks with valid jump kinds, and the jump target is never null.

[BruceForstall]

Since bbJumpDest is part of a union, the "tag" or type of which is the bbJumpKind, it generally seems semantically illegal to access bbJumpDest without first checking bbJumpKind. This is especially true if the union expands in the future. Structurally that isn't true, because checking bbJumpDest != nullptr is the same as checking bbJumpSwt != nullptr. It would be nice to "hide" that in a BasicBlock predicate function, so we can get the same throughput as today with better encapsulation of that detail.

In general, it makes sense to always null out bbJumpDest if the bbJumpKind doesn't use it, and require it be non-null if bbJumpKind requires it. It makes for a simple, easy-to-understand invariant. During block creation, it might require some refactoring to achieve that, perhaps by deferring setting the kind until the dest is known?

I dislike HasJumpTo(nullptr) (maybe HasJumpTo(block) should assert(block != nullptr)), so having a HasJump() instead makes sense.

[amanasifkhalid]

During block creation, it might require some refactoring to achieve that, perhaps by deferring setting the kind until the dest is known?

I dislike HasJumpTo(nullptr) (maybe HasJumpTo(block) should assert(block != nullptr)), so having a HasJump() instead makes sense.

The bbNewBasicBlock refactor sounds like a good idea. I'll include that and the HasJump() work in a follow-up PR.

[amanasifkhalid]

FYI: small TP diffs.

[AndyAyersMS]

Mostly looks good...

[AndyAyersMS]

It seems odd that SetJumpKind has a Compiler* arg but SetJumpKindAndTarget doesn't. I would expect the latter to be a logical superset.

If you added a Compiler* arg you could then fix the switch version to allocate the BBswtDesc automatically, perhaps.

[amanasifkhalid]

@AndyAyersMS I initially intended for us to use SetJumpKindAndTarget only for blocks that have a jump, so we wouldn't have a scenario where we need the Compiler* arg to assert BBJ_NONE is being used correctly. But if you'd prefer, I can adjust this implementation so that we use SetJumpKindAndTarget for all blocks regardless of jump type (where the jumpDest arg is null for blocks without jumps), and add a Compiler* arg to it so we can do the BBJ_NONE-related assertions. This approach would help us enforce bbJumpDest is null for blocks without jumps, plus we can assert SetJumpKind and SetJumpDest are used only for blocks that have jumps so we don't break the bbJumpDest == nullptr invariant for blocks without jumps.

Should I include that change here or in the follow-up PR?

[AndyAyersMS]

Should I include that change here or in the follow-up PR?

Follow up is fine, just trying to understand where things are headed.

[AndyAyersMS]

Changes LGTM.