[llvm] [AllocToken] Fix attribute mismatch in AllocTokenPass (PR #174959)

Ayumi OHNO via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 9 04:18:27 PST 2026


ayumiohno wrote:

> Another question: how does an alloc-token function become a void() function without arguments?

`void __alloc_token_0__Znwm()` is created in the module by LowerTypeTestsPass, not existing at the beginning.

Specifically, in LowerTypeTestsPass, `ExportedFunctions` are created with a `Type::getVoidTy(M.getContext())` signature if they do not already exist in the module. The relevant code is around LowerTypeTests.cpp:2191-2210.

In Chromium CL ([https://crrev.com/c/7278839/20](https://crrev.com/c/7278839/20)) official build, `__alloc_token_0__Znwm` did not exist before LowerTypeTestsPass ran, and thus it was created as a void() function at that stage. In contrast, `_Znwm` already existed in the module from the beginning of the pipeline.


In the current IR, there is a mismatch between the callee and call site types. While FunctionCallee preserves the correct function type for the arguments (and the internal checks for AllocToken work correctly), this information does not seem to be propagated to the Module Verifier. However, based on [this discussion](https://discourse.llvm.org/t/rfc-requiring-callinst-function-type-to-match-the-type-of-the-function-being-called/86394), my understanding is that this mismatch is acceptable as IR (even if it is UB).

```
%35 = tail call noalias noundef ptr @__alloc_token_0__Znwm(i64 noundef %34) #68, !dbg !49668, !noalias !49669, !alloc_token !49672
declare !type !7989 !type !7990 void @__alloc_token_0__Znwm()
Based on [this discussion](https://discourse.llvm.org/t/rfc-requiring-callinst-function-type-to-match-the-type-of-the-function-being-called/86394), my understanding is that this mismatch should be acceptable as IR (even if it is UB), rather than a Verifier error.
```

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


More information about the llvm-commits mailing list