LLVM's C API appears to me to be missing getters for certain features. It's also very possible that the functionality is there but I can't find it, in which case I would suggest this could also be considered a documentation bug. Specifically, getters seem to be missing for the following: - the 'nsw' and 'nuw' flags on the 'add', 'sub', 'mul', and 'shl' instructions. The C API has functionality to set these flags and/or create new instructions with specific values of those flags (e.g., `LLVMBuildNSWAdd()`), but appears to have no way to query those flags on an existing instruction. - Likewise, the 'exact' flag on the 'udiv', 'sdiv', 'lshr', and 'ashr' instructions. - The various fast-math flags on floating-point operations. I don't even see how setters are exposed for these (let alone getters), but this bug is about getters. - The `LLVMAtomicRMWBinOp` associated with a particular 'atomicrmw' instruction. The BinOp can be specified when creating an 'atomicrmw' instruction with `LLVMBuildAtomicRMW()`, but I don't see a way to determine the BinOp of an existing 'atomicrmw' instruction. - The contents of an inline asm string. Despite its name, `LLVMGetInlineAsm()` appears to create inline asm values, not get information about them. - The contents of clauses of the 'landingpad' instruction. `LLVMGetClause()` exists, but it's unclear what functions can be called on the resulting `LLVMValueRef`, or how to tell the `LLVMLandingPadClauseTy` of the clause. - The operands of a 'blockaddress' constant expression. If you have a value with `LLVMBlockAddressValueKind`, how can you determine which basic block it is taking the address of? - The "prefix data" associated with a function. Again, it's very possible that getters do exist for any or all of the above, but I would suggest that in that case, this could be considered a documentation bug. I can also file separate bugs for each of these issues if desired.
Wondering if I can get a response on this? Is this a real issue, or just my user error? Thanks in advance.
Yes, this is a real issue. Unaware of this bug, I did fix some of it in https://reviews.llvm.org/D67132 , namely the issue with discovering the binop of the atomicrmw instruction. If you're willing, I'd suggest sending in patches roughly broken down to one patch per bullet point in your comment. For nsw/nuw/exact/fast-math flags, add tests to llvm-c-test, which is a program that duplicates a module using only the C API, thereby proving that appropriate getters and setters must exist to make an exact copy (or if not setters, at least set-upon-creation). You can see how I did that in my patch. The naming of LLVMGetInlineAsm is unfortunate, but I think for backwards compatibility, it would be best if it kept its current functionality. LLVMGetInlineAsmAsmString and LLVMGetInlineAsmConstraintString might have to do.
Update on this for anyone following along: https://reviews.llvm.org/D89252 addresses NSW, NUW, and Exact