[PATCH] D19641: Add an alternative to LLVMMDNode that will only accept metadata as argument.

James Y Knight via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 27 21:29:52 PDT 2016


jyknight added a comment.

In http://reviews.llvm.org/D19641#414987, @deadalnix wrote:

> @jyknight Historically, Metadata were some kind of Value. But now, Metadata has its own hierarchy. In order to expose this in the C API, we need a transition plan.
>
> The main problem here is that LLVMMDNode accept both metadata and values. Because of this, it is impossible to split the 2 right now. In order to get out of there, I want to go through a deprecation cycle for LLVMMDNode in favor of an alternative that will only accept metadata.
>
> Right now, these metadata are wrapped as value, but passing down anything else than a metadata result in an error. As a result, it is possible to switch to LLVMMetadataRef the method that produce and consume metadata at once in such a way that thing still works with outdated headers.


Okay, so you're saying that in the future, all of the things that currently say "LLVMValueRef" but are talking about metadata will be changed to say "LLVMMetadataRef", but that it will still work transparently even with old software at that point, because LLVMValueAsMetadata/LLVMGetMDNode will also be changed to return LLVMMetadataRef at the same time.

Changing the types of the functions seems somewhat questionable, but I guess it would work -- as long as people don't fail to call, (or call extraneously/incorrectly!) the new LLVMMetadataAsValue and LLVMValueAsMetadata functions.

But, those functions are really confusing right now, because they're basically no-ops (takes a value and returns the same value!), so I'd kinda expect basically everyone to get their usage wrong in the intervening period.

How many functions would need to be added if you just added LLVMMetadataRef now, along with a new version of every function that operates on metadata disguised as a value, which would operate directly on the metadata instead?


http://reviews.llvm.org/D19641





More information about the llvm-commits mailing list