- User Since
- Jan 21 2013, 11:58 AM (308 w, 1 d)
Nov 7 2018
Oct 31 2018
Oct 29 2018
Oct 28 2018
LGTM other than the argument types.
LGTM, and I am OK with merging a test later if that is more convenient. This is not a particularly complex change.
Oct 15 2018
@george-hopkins Thanks, I will take a look.
Oct 14 2018
LGTM, thanks for fixing this!
Oct 10 2018
Looks good to me now, thanks @compnerd !
Oct 8 2018
Sep 29 2018
Sep 28 2018
This broke the bots; the LLVM-C API you added should really be in Transforms/Coroutines, not Transforms/IPO. Please update the patch.
Sep 25 2018
Sep 18 2018
Ah yes, in this case the C API name (and when adding a C API, C++ API name) would be preferred over opt -help, since I imagine that anyone writing code against LLVM bindings would consult doxygen.
Sep 17 2018
I'm not sure if this function has a place here. It's not a function provided by the LLVM API, and it's platform-specific. I think with this change it would not be possible to build the OCaml bindings under MSVC, for example.
Why are there three sets of functions that all operate on LLVMValueRef? Can't we make it a single set of functions?
There is already an Llvm_target.DataLayout.t, we don't need to wrap it the second time.
Sep 15 2018
Aug 30 2018
How is a user of this API supposed to map the unsigned Kind values to something meaningful? We don't have an enum LLVMMetadataKind, do we?