This is an archive of the discontinued LLVM Phabricator instance.

Add support for attribute in the C API
AbandonedPublic

Authored by deadalnix on Apr 2 2016, 12:40 PM.

Details

Summary

There is currently no way to assign attribute to the return value and current implementation rely on deprecated code.

The old attribute mechanism is still used for instruction at this stage.

Diff Detail

Event Timeline

deadalnix updated this revision to Diff 52471.Apr 2 2016, 12:40 PM
deadalnix retitled this revision from to Add support for attribute in the C API.
deadalnix updated this object.
deadalnix added a subscriber: llvm-commits.

You should put the unrelated commits in another one, they are good clean ups.

I mirror the same comments as in D18733 regarding not directly removing the old functions.

Looks good otherwise, good work!

include/llvm-c/Core.h
1530

While I agree with the change, this is unrelated and should go into another commit.

2063

Unrelated change, in its own commit it is okay.

lib/IR/Core.cpp
927–931

Unrelated change, in its own commit it is okay.

tools/llvm-c-test/echo.cpp
771–777

As I said in D18733 a get number and get KindID at index function would make this less brute force. Alternatively a way to get them all at the same time, instead of "at index" if that is not the way that LLVM does things.

deadalnix updated this revision to Diff 52515.Apr 3 2016, 2:31 PM

Moved NFC changes to their own commit.

deadalnix added inline comments.Apr 3 2016, 2:37 PM
tools/llvm-c-test/echo.cpp
771–777

I went for the alternative first, namely mapping the attribute set. It was much bigger/more complex, and did not provide any significant advantage in real world use case.

When interacting with attribute, I usually want to check if X has attribute Y, or set attribute Y on X. Rarely do I want to iterate over all attributes (in fact, this test is the only time I ended up doing this).

This test does a lot of wasteful things on purpose in order to grill the C API. I think we are fine here.

Wallbraker added inline comments.Apr 3 2016, 4:31 PM
tools/llvm-c-test/echo.cpp
771–777

Ah that makes sense and also we discussed this on privately and came to the same conclusion. No need for the extra API.

rnk requested changes to this revision.Apr 4 2016, 10:12 AM
rnk edited edge metadata.

First, you're breaking compatibility here with old programs using LLVMAttribute. We should ask Jeurgen about that. If we decide that LLVM's underlying attribute handling has changed so drastically that we're OK with a break, then we should delete the LLVMAttribute enum.

Second, you're exposing the C++ enum values of LLVM's attributes. I have a feeling that people will start adding enum attributes in the middle to keep related attributes together. If we want to go this way, where we leverage tablegen instead of maintaining a self-contained mapping the C API layer, then the tablegen records should have manually maintained attribute numbers. We'd either use those as the direct C++ enum values or use them to generate a switch to translate from C to C++. This would be just like protobuf field ids.

This revision now requires changes to proceed.Apr 4 2016, 10:12 AM
In D18727#391285, @rnk wrote:

First, you're breaking compatibility here with old programs using LLVMAttribute. We should ask Jeurgen about that. If we decide that LLVM's underlying attribute handling has changed so drastically that we're OK with a break, then we should delete the LLVMAttribute enum.

Well LLVMAttribute are flags and we have already run out of bits, as per the comment:

/* FIXME: These attributes are currently not included in the C API as
   a temporary measure until the API/ABI impact to the C API is understood
   and the path forward agreed upon.
LLVMSanitizeAddressAttribute = 1ULL << 32,
LLVMStackProtectStrongAttribute = 1ULL<<35,
*/

So something needs to be done.

Second, you're exposing the C++ enum values of LLVM's attributes. I have a feeling that people will start adding enum attributes in the middle to keep related attributes together. If we want to go this way, where we leverage tablegen instead of maintaining a self-contained mapping the C API layer, then the tablegen records should have manually maintained attribute numbers. We'd either use those as the direct C++ enum values or use them to generate a switch to translate from C to C++. This would be just like protobuf field ids.

A translating switch sounds better, especially if the enums on the C++ side change value.

whitequark resigned from this revision.Oct 13 2017, 11:23 PM
deadalnix abandoned this revision.Oct 14 2017, 6:36 AM

Not relevant anymore.