[clang] [llvm] [Clang] Fix argument extensions in CGBlocks.cpp (PR #111740)

Eli Friedman via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 10 09:57:33 PDT 2024


efriedma-quic wrote:

> "clang::FunctionType" makes me wonder if there is actually a source-language function type available so that the signedness of the extensions could be inferred from it..? I thought these were internal calls to functions that will be emitted directly on IR...

The signature exists, in the abstract sense: the implementation of the library function is written in C code, so it has a C function signature.  It doesn't exist anywhere in the source code, but it's easy to synthesize.

On the LLVM side, we use a lower-level abstraction that says, specifically, "this is a signed integer, figure out the correct form of extension" (or "this is an unsigned integer, figure out the extension").  We do this because we don't have a richer type system available, so we need an approximation. We could also do that in clang... but we have the real C type system, so it's probably simpler to just construct the type "void *f(void*,void*,int);" and request the corresponding LLVM signature/attributes.

I mean... I guess we could go with something like the current proposal, but it seems like once we have the CreateRuntimeFunction() taking a clang signature working, it's more readable to just write C types, instead of writing an LLVM type plus a marking for whether the value is supposed to be signed or unsigned.

If we are going to go with explicitly passing in the signed-ness, though, I'd prefer a slightly different interface; instead of trying to use something that looks like an attribute, it should just be a simpler list: for each parameter, specify whether it's signed, unsigned, or not an integer.

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


More information about the cfe-commits mailing list