[clang] [Clang][AArch64][ARM]: Fix Inefficient loads/stores of _BitInt(N) (PR #93495)

[Momchil Velikov via cfe-commits]

================
@@ -2021,6 +2028,12 @@ llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) {
     assert(Value->getType()->isIntegerTy(getContext().getTypeSize(Ty)) &&
            "wrong value rep of bool");
   }
+  if (auto *BitIntTy = Ty->getAs<BitIntType>()) {
+    if (CGM.getTarget().isBitIntSignExtended(BitIntTy->isSigned()))
----------------
momchil-velikov wrote:

We might be introducing changes that are not desirable (or correct) for non-Arm targets.
Instead, I would suggest to add a description of the in-memory padding for the `_BitInt` types (e.g. via a member function in  `TargetInfo`).
One reasonable approach is lilke this:
```
enum class TargetBitInitPaddingKind {
    None,
    ZeroOrSignExtend,
    AnyExtend
};
```
where 
* `None` will be the default and will result in identical code as  the one that Clang generates now, i.e. no `sext` or `zext`, load/stores use LLVM type `iN` for `_BitInt(N)`.
* `ZeroOrSignExtend` would mean in-memory representation is padded with 0 for `unsigned _BitInt(N)` and with the sign bit for `signed _BitInt(N)`. This will be the value for AArch32
* `AnyExtend` would mean in-memory representation is padded with unspecified bits. This will be the value for AArch64. Since AFAIK we don't have such an operation in LLVM IR, one way to implement this would be identically to `ZeroOrSignExtend` or, alternatively, do zero-extend regardless of the signedness of the `_BitInt(N)` type.

https://github.com/llvm/llvm-project/pull/93495