I was trying to think of why your changes would affect these tests, since they all use a custom operator (_test::dummy). And... it's probably because we now register a CPU fallback kernel to the Lazy key in core? It would probably be better if we just arranged for this test to get built without any of the dispatcher registrations running :p.

Either way, removing seems totally fine.

yes, the fallback affects these.

actually, there is another PR out (#73973) which I wanted you to take a look at, and I plan to land after this. Once that's in, i think we could more easily run tests like this, however, it also doesn't seem like that important of a test to me given the other coverage we'll be adding

If this ends up being important, the sizes thing is fixable - @swolchok recently landed something to fix a similar issue for NestedTensor: #73817

Yea, I spoke to him briefly; his fix only fixed one method, and I think we need to fix all the other ones too

Does comparing with nullptr mean LTC_TS_CUDA=0 would also set the device to kCUDA? I see we are using GetEnvBool in our branch.

yea, it is not ideal. I copied the way that LTC_.._dynamic shapes mode is set (see ir.cpp)

I think we should change this, but propose to unify them all in a later PR and have one system that lets us override any of the 'FLAGS_' variables using envs with a consistent naming.

I don't fully understand how per_operator_headers works, so just curious why we need to add the extra headers here?

tldr: we used to get away with #include <ATen/Functions.h>, which would include every tensor operator (easy for development, but bloats all of our C++ files). The per_operator_headers stuff basically generates a new header file for every aten operator, and enforces that you only include the headers for the operators that you actually need.

The codegen uses the metadata in native_functions.yaml to figure out which #includes to stamp out, but there are a few ops that are hardcoded directly into the RegisterDispatchKey.cpp template file (that we need to hardcode here, because the codegen would know to include them just based on the yaml).

My guess for why we needed that extra _copy_from_and_resize op is because the LTC codegen uses it directly (to handle inplace/out= ops)

Why do we need the flag in gen_backend_stubs.py (I thought it wasn't used by LTC?)

Also, I think a light comment here on why we have build_in_tree would be nice. Basically, gen_backend_stubs.py was originally meant as a codegen pipeline for external backends that don't have the ability to take advantage of native_functions.yaml and our core codegen pipeline. And now that LTC is a part of core, it may or may not get built in-tree (depending on whether the backend that hooks into LTC is in-tree or not).

ohh it's just because gen_lazy_tensor.py calls into the function in gen_backend_stubs.py (so if you're adding a new flag for the LTC codegen, the backend_stubs function needs to know about it). I guess that's fine, since the gen_backend_stubs.py entrypoint isn't affected - just the helper functions it uses. (Maybe just include in the comment here that it's only actually needed/used by LTC codegen)

I added a comment locally, but if my CI is clean this time I'm gonna land the comment in a separate diff haha