aboutsummaryrefslogtreecommitdiff
path: root/src/zig_llvm.cpp
diff options
context:
space:
mode:
authorAndrew Kelley <andrew@ziglang.org>2022-08-01 23:26:36 -0700
committerAndrew Kelley <andrew@ziglang.org>2022-08-01 23:26:36 -0700
commit44f833129c81bfa7117743fc7d54c44db09cc240 (patch)
tree12f9d4dcf288019db49293c55935edca7e9262ab /src/zig_llvm.cpp
parent9e4091200e165db808216ad2a340c6ed4f18c494 (diff)
downloadzig-44f833129c81bfa7117743fc7d54c44db09cc240.tar.gz
zig-44f833129c81bfa7117743fc7d54c44db09cc240.zip
LLVM backends: work around poorly designed C API
As part of the Opaque Pointers upgrade documentation, LLVM says that the function LLVMGetGEPSourceElementType() can be used to obtain element type information in lieu of LLVMGetElementType(), however, this function actually returns the struct type, not the field type. The GEP instruction does store the information we need, however, this is not exposed in the C API. It seems like they accidentally exposed the wrong field, because one would never need the struct type since one must already pass it directly to the GEP instruction, so one will always have it handy, whereas one will usually not have the field type handy.
Diffstat (limited to 'src/zig_llvm.cpp')
-rw-r--r--src/zig_llvm.cpp4
1 files changed, 4 insertions, 0 deletions
diff --git a/src/zig_llvm.cpp b/src/zig_llvm.cpp
index a1b0f6a30c..4f9cd76c6a 100644
--- a/src/zig_llvm.cpp
+++ b/src/zig_llvm.cpp
@@ -1195,6 +1195,10 @@ void ZigLLVMSetCallElemTypeAttr(LLVMValueRef Call, size_t arg_index, LLVMTypeRef
Attribute::get(call_inst->getContext(), Attribute::ElementType, llvm_type));
}
+LLVMTypeRef ZigLLVMGetGEPResultElementType(LLVMValueRef GEP) {
+ return wrap(unwrap<GEPOperator>(GEP)->getResultElementType());
+}
+
void ZigLLVMFunctionSetPrefixData(LLVMValueRef function, LLVMValueRef data) {
unwrap<Function>(function)->setPrefixData(unwrap<Constant>(data));
}