Skip to content
This repository was archived by the owner on Oct 7, 2025. It is now read-only.

[RFC] Moving TSL into XLA #100

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[RFC] Moving TSL into XLA #100

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions rfcs/20231212-moving-tsl-into-xla.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Moving TSL to XLA
| Status | Proposed |
| :------------ | :------------------------------------------------------ |
| **RFC #** | [100](https://github.com/openxla/community/pull/100) |
| **Authors** | David Dunleavy ([email protected]) |
| **Sponsor** | Puneith Kaul ([email protected]) |
| **Updated** | 2023-12-12

## Objective
Move [TSL](https://github.com/google/tsl) to [XLA](https://github.com/openxla/xla).
## Proposal
TSL was originally utility and support libraries in TensorFlow needed by XLA.
Instead of moving the utility and support libraries directly to the openxla/xla repo, TSL was created anticipating
that other projects might want to move out of TensorFlow. In this case, TSL would provide common support code for
potentially many projects, not just XLA.
However, since TSL's creation over a year ago, XLA is the only direcet dependent of TSL, so we are in the process
of planning to move to TSL into XLA under the `tsl/` subdirectory.
Copy link
Contributor

@joker-eph joker-eph Feb 14, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for elaborating :)

We will use `bazel query` or similar to enforce that TSL remains independent on XLA,
such that projects who wish to depend on only TSL, but not XLA won't experience bloated binary sizes.
This work is currently planned to start in early Q1, so it would be great to hear any feedback or concerns with this
plan before January 12th, 2024.
Thanks!