Details
Diff Detail
Event Timeline
tools/llvm-c-test/echo.cpp | ||
---|---|---|
295 | Why did you remove this? |
tools/llvm-c-test/echo.cpp | ||
---|---|---|
295 | The exact same test is also at the top of the function. |
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 | Are these value stable ? | |
tools/llvm-c-test/echo.cpp | ||
295 | No it is not. |
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:
- Slow (many bindings use libffi)
- Usually cannot be inlined (see 1)
- 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.
tools/llvm-c-test/echo.cpp | ||
---|---|---|
295 | Ah. I misread. I will add it back in. |
include/llvm-c/Core.h | ||
---|---|---|
252 | 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. |
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.
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.
Are these value stable ?