[LLVMdev] [RFC] LLVM C-API Change

Bill Wendling wendling at apple.com
Thu Oct 18 01:35:37 PDT 2012


I recently reimplemented the Attributes class. It now hides the data representation inside of an opaque class. In the near future, we will be extending this class to encompass many other attributes.

The changes pose one problem, however. The C-API still uses the old data representation for passing along the Attributes class. In particular, these two functions:

	LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn);
	LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg);

return the LLVMAttribute, which is an enum that happens to be the internal bit representation of the Attributes object. This is bad for several reasons, not the least of which is that it's completely inextensible (e.g., we don't have room for LLVMAddressSafety).

I would like to either remove these functions or create a new type called LLVMAttributeRef that references an Attributes object. The controversy is that this breaks the rule that C-APIs cannot change. But I don't really see an alternative, since this representation is going to become invalid with the new changes.

What are people's thoughts on this?

-bw




More information about the llvm-dev mailing list