================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
