Fix building for host architecture by default
@tpopp could you take a look? Checking, should I review this again or not (it is marked as draft)? Hi @tpopp! @RoboTux is ooo until April 11th. He asked me to let you know he wanted to have a look at the CI failures before taking it out of draft. Cheers and have a nice weekend! > Hi @tpopp! @RoboTux is ooo until April 11th. He asked me to let you know he wanted to have a look at the CI failures before taking it out of draft. Cheers and have a nice weekend!

I'm slowly catching up but the problem seems to be that tensorflow/python/tools/saved_model_cli_test.py assumes both x86 and aarch64 are always available. I'll see how to remove that expectation on Monday, any suggestion welcome though. I'll share it with others in the US in hopes that someone else has thoughts but won't be able to look earlier than Monday or Tuesday myself.  FYI: I have a revised patch that I'm going to push shortly (probably tomorrow). That should fix the python test failures observed with the current patch. Hey, sorry, I just came back from vacation. I'm going to see if I can find a more appropriate person to review this and will try to, in parallel, make sure everything passes, so there are no unexpected surprises later. To me it seems like @jakeharmon8 and @MichaelHudgins might be the ones who should look at this? Failure seems unrelated:
"ModuleNotFoundError: No module named 'tensorflow.compiler.mlir.stablehlo'"

It also passed CI before this last merge. > Failure seems unrelated: "ModuleNotFoundError: No module named 'tensorflow.compiler.mlir.stablehlo'"
> 
> It also passed CI before this last merge.

Same error on master as well: https://github.com/tensorflow/tensorflow/actions/runs/5010911951/jobs/8981212479 @RoboTux That failure was introduced with https://github.com/tensorflow/tensorflow/commit/c09dcc2c7d07a84cdb9f9b5342d7803f5dbc50b3 @vam-google or @jakeharmon8 could you PTAL? Ping? @RoboTux can you please take a look at the errors in "Py+CPP Test Suite - Ubuntu CPU, Python 3.9".  They do look related to the PR  I'm working on fixing remaining issues. The latest push should fix the API and codestyle issues. Note: this does indeed introduce a new function in the test API and follows a similar pattern to ROCm and cuda. Let me know if it isn't fine. All remaining issues seem unrelated to this change:
- Arm CI fails to find the pip package it created (ls: cannot access '/tensorflow/whl/-*310*310*.whl': No such file or directory)
- AMD ROCm fails to find clang
- MacOS has 16 tests timing out @jakeharmon8 @MichaelHudgins  Ping? @jakeharmon8 can you rereview? 
@RoboTux can you please rebase? > @jakeharmon8 can you rereview? @RoboTux can you please rebase?

Sure thing, done. Windows build failure looks unrelated:

```
external/llvm-project/mlir/lib/Interfaces/ViewLikeInterface.cpp(118): error C2065: 'not': undeclared identifier
external/llvm-project/mlir/lib/Interfaces/ViewLikeInterface.cpp(118): error C2146: syntax error: missing ')' before identifier 'scalables'
external/llvm-project/mlir/lib/Interfaces/ViewLikeInterface.cpp(118): error C2059: syntax error: ')'
external/llvm-project/mlir/lib/Interfaces/ViewLikeInterface.cpp(119): error C2146: syntax error: missing ';' before identifier 'printer'
``` MacOS build seems to fail for performance reasons if I read this correctly:
```
//tensorflow/python/kernel_tests/linalg/sparse:csr_sparse_matrix_sparse_mat_mul_grad_test_cpu FAILED in 150 out of 150 in 1.2s
  Stats over 150 runs: max = 1.2s, min = 0.5s, avg = 0.8s, dev = 0.1s
```

Since this code only changes the build system that must be unrelated.

As to ARM CI there is one test where TF crashes which I'm not sure about and one x86 dialect loading failure which is most likely related to this diff. I'll have a look now

```
FAIL: //tensorflow/compiler/xla/mlir/math/transforms/tests:math_optimization.mlir.test
(...)
LLVM ERROR: Building op `x86vector.avx.rsqrt` but it isn't registered in this MLIRContext: the dialect may not be loaded or this operation isn't registered by the dialect.
``` //tensorflow/dtensor/mlir/tests:spmd_expansion.mlir.test is known as flaky, see https://github.com/tensorflow/tensorflow/issues/61164 Hi @RoboTux Can you please resolve conflicts? Thank you! fyi - @RoboTux is on leave until 26th. I can confirm that this PR works for Windows CUDA build. The remaining are resolving conflicts and merge quickly before new merge conflicts happens. Ping? There are two more blockers that I'm working on:

1) Internal technical issues that I should have fixed soon
2) Changes to the API normally require an RFC+Review (see [here](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md)). I'm looking into what the process is for external contributors, and whether or not there's a shorter process for small changes like this. If you'd like to avoid that red tape, you could refactor this to remove the API changes. > There are two more blockers that I'm working on:
> 
>     1. Internal technical issues that I should have fixed soon
> 
>     2. Changes to the API normally require an RFC+Review (see [here](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md)). I'm looking into what the process is for external contributors, and whether or not there's a shorter process for small changes like this. If you'd like to avoid that red tape, you could refactor this to remove the API changes.

I'm not sure how I could remove the API change. I need a way to skip a target CPU specific test if the support for that target is not built in so need a way to query that.
By default Tensorflow build aims to only build what is relevant for the host targets. However, due to some missing guards here and there code for other architecture may end up being built. For instance, when building tensorflow/compiler/mlir:tf-opt on AArch64 code specific to x86 also ends up being built. This commit fixes that (aka issue #59595).