Update Tensorflow to 2.16.1

[CNugteren]

What do these changes do?

Very much a draft, only updated TF itself, CI, and Bazel so far. Still to be done: update the actual C++ code as needed.

The main reason for updating TF is that it will add support for Python 3.12 builds.

TODO

• Tom updated the code by continuing to compile until there were no more compilation errors, but we should check the actual changes of the MLIR code between TF 2.13 and 2.16: its very likely that we have to add/remove/modify some MLIR passes.
• Tom removed the addBenefit arguments from the TableGen rules. We should check if this doesn't introduce problems.
• Use the new TF_PYTHON_VERSION environment variable in CI
• Test release jobs
  • First release jobs are running here, mostly to start populating the bazel caches:
    attempt1
    attempt2 The linux jobs are running out of disk space.
    attempt3
    attempt4
    attempt5 macOS builds now fixed, linux still out of disk space
    attempt6 (used hacky action that removes installed software from github runner in order to maximize disk space, but doesn't work in combination with docker)
    attempt7 Linux builds fixed, by using /mnt folder of github runner to store bazel output
    https://github.com/larq/compute-engine/actions/runs/9586972348 Use workspace name "lce" on Windows build for shorter paths.
• Fix windows builds (see this error for example). This is (very very likely) due to the 260 path length limit in MSVC.
  It tries to access C:/build_output/execroot/larq-compute-engine/bazel-out/x64_windows-opt/bin/external/org_tensorflow/tensorflow/compiler/mlir/quantization/tensorflow/calibrator/_objs/calibration_statistics_collector_average_min_max/calibration_statistics_collector_average_min_max.obj.params which is 274 characters, so we need to remove at least 14 (or 15?) characters from this.
  • We could change C:/build_output to C:/bzl
  • We could change workspace(name = "larq_compute_engine") to workspace(name = "lce")
  • With those combined the path (at least for this compiled file) would become short enough.
  • This combination is being tested here ✔️ It worked!

[Tombana]

There is now an extra argument before the benefit-argument. So we could either insert a [], here before addBenefit, or just remove the benefit thing alltogether. @lgeiger do you know if we depend on these benefit values? A lot of them seem arbitrary to me, but some seem to be chosen specifically.

[Tombana]

I looked through the patterns again, and I added back one of the addBenefits and left all the others out.

The one I added back was in order to give priority to GreaterEqual(x, 0) -> Quantize pattern over the more generic GreaterEqual(x, threshold) -> Quantize(x - threshold) pattern. This might avoid a 'subtract 0' operation.
For all other patterns, I don't think the benefit value really mattered: you could first convert a ste.sign(x) to Quantize(Dequantize(x)) or first convert a Conv to a Bconv; that order does not matter. (Besides, it only applies to patterns within one pass)

[CNugteren]

Thanks for going through all this effort @Tombana 🙏 Looks ready to merge to me (I can't approve since I'm the original author of the PR) 👍 .

[lgeiger]

Awesome! Thank you so much for upgrading 🙏

[lgeiger]

Should we still keep --distinct_host_configuration=false? Though happy to keep it as is if it works

[Tombana]

That flag was removed in this bazel version :)
I think it would still be nice to have the same effect to avoid a few double builds, but in order to achieve that with the new bazel I think you have to do add some complex toolchain files.