This is an archive of the discontinued LLVM Phabricator instance.

[llvm-c] Improve IR Introspection: Add ValueKind
ClosedPublic

Authored by ubsan on Apr 2 2016, 1:12 PM.

Details

Summary

Bringing D2176 to modernity

Adds:

  • LLVMValueKind
  • LLVMGetValueKind

Diff Detail

Repository
rL LLVM

Event Timeline

ubsan updated this revision to Diff 52473.Apr 2 2016, 1:12 PM
ubsan retitled this revision from to [llvm-c] Improve IR Introspection: Add enums.
ubsan updated this object.
ubsan added a reviewer: whitequark.
ubsan added a subscriber: llvm-commits.
ubsan updated this revision to Diff 52481.Apr 2 2016, 2:47 PM
ubsan updated this object.

I'm sorry, learning the tools :)

ubsan updated this revision to Diff 52482.Apr 2 2016, 2:53 PM
ubsan updated this object.

listening to whitequark :P

ubsan updated this revision to Diff 52488.Apr 2 2016, 7:57 PM

Add tests, fix that switch in LLVMGetValueKind

whitequark added inline comments.Apr 3 2016, 3:46 AM
tools/llvm-c-test/echo.cpp
295 ↗(On Diff #52488)

Why did you remove this?

ubsan added inline comments.Apr 3 2016, 2:49 PM
tools/llvm-c-test/echo.cpp
295 ↗(On Diff #52488)

The exact same test is also at the top of the function.

ubsan retitled this revision from [llvm-c] Improve IR Introspection: Add enums to [llvm-c] Improve IR Introspection: Add ValueKind.Apr 3 2016, 2:50 PM

Could you use arc next time to submit a patch ? It is very hard to see if there is missing checks in the test.

Overall, if the stability of these values cannot be guaranteed then that is an issue and a mechanism to retrieve the ID, either from a string or from a C enum with guaranteed values.

More generally, I'm not sure how much value does this bring to the table as it seems fairly redundant with the LLVMIsAXXXX mechanism. It can be argued that it create a few extra tests, but using the C API means wrapping and unwrapping all the time, and doing these check in the process, so I'm not sure it is worth it.

include/llvm-c/Core.h
252 ↗(On Diff #52488)

Are these value stable ?

tools/llvm-c-test/echo.cpp
295 ↗(On Diff #52488)

No it is not.

whitequark edited edge metadata.Apr 3 2016, 3:09 PM

The reason the table exists is for bindings. Without LLVMGetValueKind(), a binding that wishes to introspect an instruction has to call the multitude of LLVMIsA* functions in sequence, which is:

  1. Slow (many bindings use libffi)
  2. Usually cannot be inlined (see 1)
  3. Fragile and hostile to upgrades of LLVM, as there isn't even an easy way to figure out the type of the value that broke the check

If you guys think exposing this id is a good idea I won't oppose it. If I understand correctly, you want to avoid calling into LLVM too much in case the call itself is expensive ? It seems to me that the C API doesn't do a very good job at reducing the amount of calls, for instance various instructions cannot be built without multiple calls (among the worse offenders, landingpads). There is probably lower hanging fruits in that tree.

Anyway, as long as the enum value are stable, I'm won't oppose this. I just wanted to make sure you understands that goign froward with this means having an enum to maintain like forever.

ubsan added inline comments.Apr 4 2016, 7:32 AM
tools/llvm-c-test/echo.cpp
295 ↗(On Diff #52488)

Ah. I misread. I will add it back in.

ubsan added inline comments.Apr 4 2016, 11:30 AM
include/llvm-c/Core.h
252 ↗(On Diff #52488)

No... hmm, you're right. We could still do this, but we would not be able to use Value.def, because we have to make LLVMInstructionValueKind the last.

ubsan updated this revision to Diff 52591.Apr 4 2016, 11:56 AM
ubsan edited edge metadata.

Fix deadalnix's problems with the revision.

So how this would work is; any additional values would be added after LLVMInstructionValueKind, and if any values are removed, they would be removed in this enum, and the values would have integer values assigned.

whitequark accepted this revision.Apr 4 2016, 12:44 PM
whitequark edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Apr 4 2016, 12:44 PM

Ok one last thing. In the test, that'd be great to check that a cloned value has the same value kind as the "clonee" in the test.

ubsan updated this revision to Diff 52694.Apr 5 2016, 8:35 AM
ubsan edited edge metadata.

Add checks for the Ret value as well

deadalnix added inline comments.Apr 5 2016, 11:17 AM
tools/llvm-c-test/echo.cpp
230–231 ↗(On Diff #52694)

Instead of reproducing this pattern of over the place, I think it would make sense to factor it out.

297 ↗(On Diff #52694)

Keep the comment please.

ubsan updated this revision to Diff 52765.Apr 5 2016, 10:46 PM

Coalesce the checks.

This revision was automatically updated to reflect the committed changes.