MPS: `torch.sub` erroneously returns 0 on outputs of `chunk` via `layer_norm`
Labels: triaged, module: mps

### 🐛 Describe the bug

When calling `chunk(2)` on the output of a complex unet model that includes at least `layer_norm()`, subtracting the tensors returned from  the `chunk()` call from each other yields - incorrectly - a tensor full of zeroes. If the second tensor is `clone()`d or if both are sent to `cpu()` before subtracting, valid output is produced.

I do not yet have a concise repro case, but the symptom is the following:

```python
ab = stable_diffusion_unet_model.forward(...)
a, b = ab.chunk(2)
# a, b have device mps:0
test1 = a - b
# test1 is all 0s
test2 = a - b.clone()
# test2 has what looks like valid output
test3 = a.clone() - b
# test3 is all 0s
test4 = a.cpu() - b.cpu()
# test4 has what looks like valid output, matching test2
```

I have managed to trace the earliest site of corruption as a call to `layer_norm` inside `stable_diffusion_unet_model.forward(...)`. however, trying to reproduce in a simple python session using `torch.randn()` and passing that directly to `layer_norm` i'm not able to reproduce the issue.

In order to debug this I have set myself up with a native MPS debugging session, and I've added a `__builtin_debugtrap()` to the call to `torch.sub()`. However I've reached a limit of publically available documentation. My assumption is that something about how `chunk()` is implemented is messing up the call to `sub()` and/or giving it insufficient information to resolve whatever offsets it needs to resolve to actually get the tensor data it needs. 

Upon adding some printing code to the top of `binaryOpTensor()` in `BinaryOps.mm`, like this:

```
  const auto sub_op_name = "sub_out_mps:";
  if (op_name == sub_op_name) {
    std::cout<<op_name<<": enter binaryOpTensor"<<std::endl;
    stream_out_tensor(std::cout<<op_name<<": self: ", self, 8)<<std::endl;
    stream_out_tensor(std::cout<<op_name<<": other: ", other, 8)<<std::endl;
    std::cout << self.options() << std::endl;

    __builtin_debugtrap();
  }
```

and after rebuilding pytorch in DEBUG mode, [which i have documented here](https://medium.com/@damian0815/how-to-debug-native-mps-operations-in-pytorch-f094b7f4e8f0), and running `lldb -- python scripts/my_script.py` with the Python code that triggers the bug, I get the following output:

```
sub_out_mps:: enter binaryOpTensor
sub_out_mps:: self: -27530939119479883300864.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 
sub_out_mps:: other: -27530939119479883300864.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 
TensorOptions(dtype=float, device=mps:0, layout=Strided, requires_grad=false (default), pinned_memory=false (default), memory_format=(nullopt))
Process 98436 stopped
(lldb)
```

Note that `stream_out_tensor` is adapted from `PRINT_TENSOR()` in `MPSCNNTests.mm`, which prints `t.data_ptr<float>()[i]]` - I assume this is wrong, which is why I'm seeing `-27530939119479883300864.00`. nevertheless It's suspicious that both `self` and `other` have the same number, but without better documentation I'm just guessing.

Additionally, in the lldb session I can determine that `self` and `other` are both non-view tensors with contiguous memory and a storage offset of 0:

```
(lldb) expr other.storage_offset()
(int64_t) $4 = 0
(lldb) expr self.storage_offset()
(int64_t) $5 = 0
(lldb) expr self.is_view()
(bool) $6 = false
(lldb) expr other.is_view()
(bool) $7 = false
(lldb) expr other.is_contiguous(c10::MemoryFormat::Contiguous)
(bool) $8 = true
(lldb) expr self.is_contiguous(c10::MemoryFormat::Contiguous)
(bool) $9 = true
```

Given as how they each result from a call to `chunk(2)` I'm not sure how this can be the case, unless something upstream of `binaryOpTensor` is copying them to contiguous memory -- but then, I'd expect different values to be printed above:

```
sub_out_mps:: self: -27530939119479883300864.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 
sub_out_mps:: other: -27530939119479883300864.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 
```
 rather than each showing `-27530939119479883300864.00`.

Posting here in the hope that @kulinseth or someone else with MPS knowledge will be able to point me in the right direction. Better yet would be an invite to y'all's Slack, but I do understand why you'd want to keep that more tightly controlled.

### Versions

```
Collecting environment information...
PyTorch version: 1.14.0a0+gitdc40b6d
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.0.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: version 3.21.4
Libc version: N/A

Python version: 3.10.8 | packaged by conda-forge | (main, Nov 22 2022, 08:25:13) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.0.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] pytorch-lightning==1.7.7
[pip3] torch==1.14.0a0+gitdc40b6d
[pip3] torch-fidelity==0.3.0
[pip3] torchdiffeq==0.2.3
[pip3] torchmetrics==0.10.3
[pip3] torchsde==0.2.5
[pip3] torchvision==0.13.1
[conda] Could not collect
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev