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

Amaury SECHET via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 27 23:13:19 PDT 2016


deadalnix added a comment.

> 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.


Yes.

> 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.


These are opaque pointers, so that alright ABIwise. Going through the deprecation of LLVMMDNode will force people to do the right thing or get a runtime error.

> 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.


They aren't noop except LLVMMetadataAsValue, which simply checks that you pass it a metatdata. This one is not strictly necessary at this stage so maybe I can just remove it.

> 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?


13 if I'm not mistaken (including LLVMMDNode, which needs duplication either way).


http://reviews.llvm.org/D19641





More information about the llvm-commits mailing list