to reviewer note: There are no meaningful changes here, it is just tabbed over.

I think, directionally, my biggest discomfort with introducing a new GuardEnvExpr concept here that is distinct from Dynamo guards, is that Dynamo may very well WANT to generate guards like this (e.g., it is processing a conditional a is b) and it seems weird to have two possible ways to generate a guard (regular Guard, or GuardEnvExpr)

Agreed, it would be good to consolidate how we manage guards into a single place. That doesn't mean all guards need to be sympy guards (or dynamo guards)

This is due to a layering issue - aot_autograd is below dynamo, so this needs to be in another place. We could violate layering and reuse the definitions in guards.py, or we could lower those down to a shared place, or we could do something like this. This felt the more reasonable, especially given the fact that we have another guard system in shape_env already that follows a similar pattern.

This is also different from dynamo guards as all dynamo guards handle a single object at a time, the entire guards static_fn pattern is predicated on passing a Guard object which represent a single arg (see the self.get calls in guards.py). We could break that assumption and make multi-target guards, and rewrite that file, or we could carve out a special one-off guard that takes multiple tensors.

Fwiw, I understand the concern, and we could do something like:

1. throw out DuplicateInputs
2. Make the mapping tensor:source instead of tensor:name
3. define a new Guard type that is multi-source / or a Source type that is multi-guard (we need to model the fact that this is a 2 object guard somewhere)
4. Call Guards.DUPLICATE_INPUTS with either the 2 object guard, or with 2 guards for the 2 sources

Would you prefer that? Does that feel cleaner to you both? it does not to me.

This with can go around the function call instead of the def ... part. The env doesn't matter for a function def. This will make this file's diff easier to read.

Done! I added a comment about why it is where it is too.

How are we passing the shape env to each part of the stack today? Is it a different global variable somewhere? I'd suggest some sort of tracing context class (and if needed just one global pointer to that) that holds pointers to these sorts of things and also allows us to guarantee they are set.

ShapeEnv is accessible from all SymInts, so all the points when we may want to register guards (e.g. an equality test on symint) can just directly add the guard to the SymInt. So ShapeEnv didn't really need a context class (although maybe it should.)

We were talking about global vs passed around and Ed suggested this dynamic scoping to be a medium between the two. I don't have strong opinions on either way, but the plumbing story right now to backends is not amazing (as you recall from the kwargs/pass fake_mode around PRs we tried and failed prior).

There's a few ways we could take this:

1. Leave as is, its a one off for now, until another thing with a similar lifecycle and pass-through-backends story needs to be developed
2. Match the fake_mode pattern more closely, and ride guard_env down on the inputs (I dislike it, but its worth mentioning for consistency)
3. Make a tracing context we pass around, move the shape_env and guard_env there