Repository: pytorch
Issue: Barriers to using torch.compile directly in PyTorch library code
Labels: feature,triaged,oncall: pt2,module: inductor,module: dynamo

### 🐛 Describe the bug

There are many places in the PyTorch eager API where we could conceivably write a kernel for something, but we it's annoying / time consuming to do so / increases our binary size. 

For example, in https://github.com/pytorch/pytorch/pull/101115 we don't have a deterministic implementation of upsample_bilinear backwards and implementing one would be pretty annoying (the most plausible approach is to redo the CUDA kernel with the iteration space on grad_input rather than grad_output (which necessitates atomic adds). However, we could instead use torch.compile to compile us an implementation of the backwards! Assuming that torch.compile has a deterministic implementation of scatter (it doesn't, but we could conceivably do it by going to eager's deterministic implementation.)

So ideally, you'd like to modify code in PyTorch's Python frontend to look like this:

```
    if input.dim() == 4 and mode == "bilinear":
        assert align_corners is not None
        if antialias:
            return torch._C._nn._upsample_bilinear2d_aa(input, output_size, align_corners, scale_factors)
        if torch.are_deterministic_algorithms_enabled() and input.is_cuda:
            return torch.compile(torch._C._nn.upsample_bilinear2d, dynamic=True)(input, output_size, align_corners, scale_factors)
        else:
            return torch._C._nn.upsample_bilinear2d(input, output_size, align_corners, scale_factors)
```

However, there are a few problems to doing this:

1. This breaks torch.compile! If you modify a function which is allow_in_graph'ed, during Dynamo execution we will send fake tensors through the arguments, but if you recursively hit torch.compile it will choke as it doesn't know how to deal with fake tensors.
2. The warmup time is bad! It takes a long time to compile, and if you hit the function at multiple sizes we will compile a few times before quiescing dynamic=True. https://github.com/pytorch/pytorch/pull/101027 could potentially help here.
3. It goops up observability! Most users of our logging and debug tools assume that they will only get logs for their actual model, and no PT2 logs when they are running stock eager code. This breaks this assumption, since random eager code can trigger compile. (I also ran into this with https://github.com/pytorch/pytorch/pull/99809)
4. Performance might be bad! These are small graphs and guard overhead is a lot more notable in these situations.

What I am kind of imagining is that we need some alternative frontend to torch.compile which is specialized for "single function optimize me" use case. This frontend can be export oriented; e.g., we won't recompile unless you explicitly bump a version number or something and should aggressively cache its compile products to disk.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @ngimel @Xia-Weiwen @soumith @Chillee 

### Versions

master