[llvm-branch-commits] [clang] [Clang][CodeGen] Implement code generation for __builtin_infer_alloc_token() (PR #156842)
Marco Elver via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Mon Oct 20 07:20:30 PDT 2025
melver wrote:
> Ok, so one thing I see in the tests is a similar issue to what I've been looking at while prepping the tmo feature - the tests are essentially "random looking number". We've had regressions in the past as a result of the tests being essentially opaque - I'm unsure if it's worth you addressing this here as I'll be looking to address it while upstreaming the tmo functionality in which case we're just duplicating effort.
Only the constexpr tests (previous PRs in the series) do test the hashes, simply because of there no being intermediate testable step. But for CodeGen (here) we can actually test the !alloc_token intermediate metadata before that is turned into a hash.
> One thing that seems weird to me is that you're emitting an llvm runtime call to alloc_token_id - I've been dealing with ptrauth for long enough for brain overflow (and I do have real memory problems :-/) so I'm sorry if I've forgotten the rationale, but my expectation was that this should be producing a constant token (it needs to be const evaluable for templates, etc).
The pointerhash* modes are constexpr (previous PRs in chain), but the stateful modes aren't. Here I'm deliberately testing one of those stateful modes (random) so I can test the intermediate !alloc_token, otherwise it'd be also the random looking numbers we could test here. I will document that better in the test.
> I also realized my original dream (return the pseudo type) doesn't work because C would have no wait to understand it, and C++ would have only marginally less difficulty.
The next best thing is what we have here, where we test the !alloc_token being generated, but that requires us forcing a stateful mode where Clang doesn't constant evaluate it before. I think it's a decent compromise, as it does test the type inference logic, which is shared with the constant evaluation logic as well.
https://github.com/llvm/llvm-project/pull/156842
More information about the llvm-branch-commits
mailing list