melver wrote:

> I would really prefer the codegen changes to be separate from the inference 
> pass.

In this change, or in preceding ones?

> What I _really_ want is a __builtin_infer_allocation_type(expr) that somehow 
> produces a human readable output - for the purpose of testing mostly as it's 
> of questionable real world use. You could imagine a hypothetical case where 
> it returns a human readable description of the inferred type information, and 
> a developer _could_ have a custom type descriptor that was "hash the string". 
> Though I remain on the "this would still be of questionable value outside of 
> test" side of the fence.

Where are those tests?
In the LLVM repo or outside?
Because if it's inside the LLVM repo, we can already do exactly that, and 
that's also what the clang/test/CodeGenCXX/alloc-token-builtin.cpp test 
currently does (in one case it does not let the IR pass run, so we can check 
the type it inferred in the metadata). Of course, should all this become 
constexpr, we need the 2nd builtin.

> Regardless, I'd then expect both `__builtin_infer_allocation_type` and 
> `__builtin_infer_allocation_token` to call the same underlying inference 
> routine, and just convert the output differently.
> 
> `__builtin_infer_allocation*` also need to be able to be constant evaluated 
> so the can be used in consteval contexts, though that should just be a matter 
> of calling the method that does the inference, and then wrapping that in the 
> appropriate CE container

For the `__builtin_infer_allocation_type` that'd be ok, but for 
`__builtin_infer_allocation_token` that won't work, because then we have to 
pull out all the token calculation logic in a way that Clang can access it. And 
some of that depends on configuration specific to the LLVM IR pass, that is not 
yet known. Not sure if there's a clean way other than somehow creating an API 
that can be used to do the token calculation that can be shared between Clang 
and IR pass.

Preferences?

https://github.com/llvm/llvm-project/pull/156842
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to