diff options
author | Mariya Podchishchaeva <mariya.podchishchaeva@intel.com> | 2024-07-15 09:40:39 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-07-15 09:40:39 +0200 |
commit | 9ad72df55cb74b29193270c28f6974d2af8e0b71 (patch) | |
tree | 7c5f33e97191ca6bca1785ac327a4a14d834e5ae /clang/lib/CodeGen/CodeGenFunction.cpp | |
parent | 9ac2b8965264a7f20a3e07c913b25c375a080c0f (diff) | |
download | llvm-9ad72df55cb74b29193270c28f6974d2af8e0b71.zip llvm-9ad72df55cb74b29193270c28f6974d2af8e0b71.tar.gz llvm-9ad72df55cb74b29193270c28f6974d2af8e0b71.tar.bz2 |
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364)
There are two problems with _BitInt prior to this patch:
1. For at least some values of N, we cannot use LLVM's iN for the type
of struct elements, array elements, allocas, global variables, and so
on, because the LLVM layout for that type does not match the high-level
layout of _BitInt(N).
Example: Currently for i128:128 targets correct implementation is
possible either for __int128 or for _BitInt(129+) with lowering to iN,
but not both, since we have now correct implementation of __int128 in
place after a21abc7.
When this happens, opaque [M x i8] types used, where M =
sizeof(_BitInt(N)).
2. LLVM doesn't guarantee any particular extension behavior for integer
types that aren't a multiple of 8. For this reason, all _BitInt types
are now have in-memory representation that is a whole number of bytes.
I.e. for example _BitInt(17) now will have memory layout type i32.
This patch also introduces concept of load/store type and adds an API to
CodeGenTypes that returns the IR type that should be used for load and
store operations. This is particularly useful for the case when a
_BitInt ends up having array of bytes as memory layout type. For
_BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and
stores of iM would both (1) produce far better code from the backends
and (2) be far more optimizable by IR passes than loads and stores of [M
x i8].
Fixes https://github.com/llvm/llvm-project/issues/85139
Fixes https://github.com/llvm/llvm-project/issues/83419
---------
Co-authored-by: John McCall <rjmccall@gmail.com>
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
-rw-r--r-- | clang/lib/CodeGen/CodeGenFunction.cpp | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp b/clang/lib/CodeGen/CodeGenFunction.cpp index 26deeca..ea4635c 100644 --- a/clang/lib/CodeGen/CodeGenFunction.cpp +++ b/clang/lib/CodeGen/CodeGenFunction.cpp @@ -233,6 +233,11 @@ llvm::Type *CodeGenFunction::ConvertType(QualType T) { return CGM.getTypes().ConvertType(T); } +llvm::Type *CodeGenFunction::convertTypeForLoadStore(QualType ASTTy, + llvm::Type *LLVMTy) { + return CGM.getTypes().convertTypeForLoadStore(ASTTy, LLVMTy); +} + TypeEvaluationKind CodeGenFunction::getEvaluationKind(QualType type) { type = type.getCanonicalType(); while (true) { |