What does this config context do?

It enables the general behavior of buffer donation. In other words, this (_xla_set_enable_alias_with_buffer_donor_config) needs to be set, so that the tensors (with the associated XLA device data backend) that were explicitly marked to be donated (_set_buffer_donation) can be donated in the next execution (i.e. mark step) [1]. It's effectively a general opt-in for the entire donation behavior (arguably we wouldn't need it since _set_buffer_donation is already assuming that the user does intend to explicitly donate it, but I just kept it as is).

#8711 describes the problem and use case, but Jack introduced this in the context of dynamo execution (#6587). Since it's an opt-in, we want to give users the flexibility to explicitly annotate the donation (precisely when they don't need the tensor after mark step). This is particularly helpful with the gradient accumulation (and scan), since we can't do in-place mutations of the fn parameters (aliasing is uncaptured by LTC), so this allows us to mitigate / close that gap. The main change in this PR, to resolve the PFR, is that we enable LTC and buffer donation to coexist (and alleviate the former constrained fallback behavior: if no LTC aliasings + user config is enabled -> donate the buffers). It doesn't alter the original intended behavior, since this heuristic is still directly maintained - but we widen the applications.

[1] XLA HLO donation ref: https://github.com/openxla/xla/blob/1c7d5f62e3b4c90a4b3484429c5042c69ceb5c5b/xla/service/hlo.proto#L479

Got it. So we need both the config and an explicit donation call.

What does sync_multi do? Is it the same as mark_step?

Mostly, but more flexible. It allows me to specify sync_xla_data=False, so that I can ensure that the aliasing is due to the user config (explicit buffer donation), and not auto LTC aliasings. So sync_ltc_data in SyncTensorsConfig will be false, so it won't include the default LTC aliasing.

I'll add a comment, since that's the motivation behind using it over mark_step.

I see you've renamed "should" to "enable". Does this imply some feature change?

Only in the sense that we allow is to run simultaneously with LTC aliasing, hence it should always be in effect. In this case, "should" for donating buffers (_set_buffer_donation) can be kept, because it may not necessarily donate it, since it depends whether this config is enabled (_xla_set_enable_alias_with_buffer_donor_config). I renamed the parameters for _xla_set_enable_alias_with_buffer_donor_config/SetAliasWithBufferDonorConfig, since we are enabling/allowing explicitly marked tensors (_set_buffer_donation) to be donated, simultaneously with LTC aliasing, so I figured that renaming it to "enable" is more suitable now.

This "user config" name is really unfortunate. It should just be called "explicit donation". I was going to suggest renaming it until I realized this is an existing feature that you exposed.

Yes, unfortunately these are tied to existing API bindings, so they could already be used by users. We could rename, but we'd have to do it over a few release cycles with a deprecation warning.