Remove endian conversion for S4/U4 literals for s390x
Hi @cheshire ,
Could you please kindly review this PR? Thank you very much! @reedwm WDYT? I think XLA changes must be submitted to the [openxla/xla](https://github.com/openxla/xla) repo, not the TensorFlow repo (CC @ddunl, correct me if I'm wrong). @yasiribmcon, can you create a new PR to the openxla/xla repo with this change and CC me? Once merged, the TF repo will automatically be updated. Yeah in principle it should be possible from here, but we have it disabled for at least the next month. So it would be great if you could reopen on openxla/xla. Feel free to tag me and I'll make sure it gets merged quickly. Hi @yasiribmcon Any update on this PR? Please. Thank you! Apologies for the delay due to christmas break @gbaned @reedwm @ddunl.
Created PR https://github.com/openxla/xla/pull/8162. Hi @gbaned Required changes have been merged with https://github.com/openxla/xla/pull/8162.
Please feel free to close this PR.
Thank you very much! > Hi @gbaned Required changes have been merged with [openxla/xla#8162](https://github.com/openxla/xla/pull/8162). Please feel free to close this PR. Thank you very much!

Hi @yasiribmcon  Thank you very much for the confirmation. 
After introducing [**_commit_**](https://github.com/linux-on-ibm-z/tensorflow/commit/e0059bba8cb4d6d3979458c0945c66b4cc1c9f69) to add support for int4(S4 and U4) types in literal, `//tensorflow/compiler/xla:literal_test` started to fail for BE(s390x) machines.

This issue is occurring in `ProtoRoundTrip` test case when we try to convert/retrieve S4/U4 literal to/from proto values.
>   auto vector_s4 = LiteralUtil::CreateR1<s4>({s4{-1}, s4{3}, s4{7}});
>   auto vector_u4 = LiteralUtil::CreateR1<u4>({u4{1}, u4{3}, u4{15}});
>   EXPECT_EQ(vector_s4, to_from_proto(vector_s4));
>   EXPECT_EQ(vector_u4, to_from_proto(vector_u4));

ConvertEndianShort assertion is failing as it expects an **even** byte size, but  for vector_s4 / vector_u4, byte size is coming as 3(odd), causing the test case to fail.

ConvertEndianShort is getting used mostly to convert **16 bit** literal types to **LE** byte order as protobuf seems to be  processing **bytes** in LE format.
> In third_party/xla/xla/xla_data.proto -
> message LiteralProto {
>   ...
>   bytes s4s = 21;
>   bytes u4s = 22;
>   ...
>   // The F16s, BF16s, U16s and S16s are encoded in little endian byte order
>   bytes f16s = 11;
>   bytes bf16s = 13;
>   bytes u16s = 16;
>   bytes s16s = 17;

Since S4/U4 underlying type is a [single](https://pypi.org/project/ml-dtypes/#:~:text=exponent%20is%200-,int4%20and%20uint4,-4%2Dbit%20integer) byte, endian conversion is not needed for S4/U4 literal types.
Hence removing endian conversion for S4/U4 integer literals types.
> using u4 = ml_dtypes::uint4;
> using s4 = ml_dtypes::int4;

After these changes, `//tensorflow/compiler/xla:literal_test` test case passes.

These changes do not cause any regressions on existing test cases and it won't affect LE machines.