[RFC] Moving TSL into XLA

[ddunl]

RFC about moving TSL into XLA. Please leave comments by Jan 12th!

[i-chaochen]

IIUC, tsl would move from xla/third_party/tsl to xla/tsl ?

[ddunl]

That's correct, that should be the only change inside the XLA repo

[ManfeiBai]

Hi, @ddunl, thanks for sharing this and here are some questions after reading the proposal:

1. would this be a one/several PR change or a long list of PRs' change?

• Currently, PyTorch/XLA update OpenXLA-pin monthly, and it seems PyTorch/XLA would include this change(@tsl to @xla/tsl) within one or several OpenXLA-pin updates;
• To avoid crash&revert, could has a list of PyTorch/XLA PRs include per change to run CI tests before merge

3. does TSL function interface be affected after the moving?

cc @miladm

[ddunl]

Hi Manfei,

1. This will be several changes (probably around 40 or so)
2. I should be able to do it in such a way that everything happens on a single pin update. PTXLA doesn't use TSL too much directly: https://github.com/search?q=repo%3Apytorch%2Fxla+%40tsl%2F%2F&type=code , and I was already planning on doing the tsl/platform code last as it is the most widely used.
3. Only the moves of the targets in the above search will be affected, so I'll make sure that you are notified as those are submitted.
4. None of the code itself should change, including symbol names (i.e. everything will still be in namespace tsl. This was a big problem moving to TSL, so I'm going to save the trouble this time and only move files and change target locations, not any of the code itself.

[joker-eph]

Nit: you're providing a good history here, but the pros/cons of doing this work aren't really stated here: can you provide some insights into this?

[ddunl]

This is a good point, I should be more explicit: it's mostly that the Copybara configurations are significantly more complex than they otherwise would be due to vendoring, so since all TSL users are also XLA users (or XLA itself), it lets us cut down on the complexity and reduce maintenance burden. I think for users of openxla/xla there is really no concrete benefit or drawback (or the benefits/drawbacks are small in magnitude), but the reduction in maintenance burden on the google side is significant. It also lets us make progress on things like the move from tensorflow/compiler/xla to third_party/xla internally.

The above logic informs the plan - given that there were no concerns raised about moving forward, the hope is that by moving it into XLA but still keeping TSL 'higher' in the dependency graph, we can let other projects who might want TSL separate from XLA in the future have it without bloated binary sizes but also do the cleanups that we want internally.

I should've elaborated more clearly on this from the start - let me know if this comment makes it clearer.

[joker-eph]

Thanks for elaborating :)