search for: llvmbool

Hi, I stumbled across the following: > /* Builds a module from the bitcode in the specified memory buffer, > returning a > reference to the module via the OutModule parameter. Returns 0 on success. > */ > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf, > LLVMModuleRef *OutModule); However in most scenarios i know, a Bool is something like 0 = False !0 = True In short: is it just me or is this really counterintuitive? -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...< > llvm-dev at lists.llvm.org> wrote: > > > > I stumbled across the following: > > /* Builds a module from the bitcode in the specified memory buffer, > returning a > > reference to the module via the OutModule parameter. Returns 0 on > success. */ > > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf, > > LLVMModuleRef *OutModule); > > However in most scenarios i know, a Bool is something like > > 0 = False > > !0 = True > > > > In short: is it just me or is this really counterintuitive? > > It is counterintu...

Okay after translating the headers to Delphi, i found more inconsistencies: > LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType, > LLVMTypeRef *ParamTypes, unsigned ParamCount, > LLVMBool IsVarArg); > In this case it is the other way around. 0 means False and anything else means true :/ (so it acts more like a "traditional" bool) 2016-09-12 11:17 GMT+02:00 Alexander Benikowski <sebal007 at googlemail.com>: > Of course, this is normal for C-APIs. But maybe ch...

...BuildRet(builder, y); (void) retInst; LLVMDisposeBuilder(builder); LLVMLinkInJIT(); LLVMLinkInInterpreter(); LLVMInitializeNativeTarget(); LLVMDumpModule(module); /* Now run it! */ LLVMExecutionEngineRef jit = NULL; char *err; // LLVMBool result = LLVMCreateExecutionEngineForModule(&jit, module, &err); LLVMBool result = LLVMCreateJITCompilerForModule(&jit, module, 0, &err); if (result) { printf("Fail: %s\n", err); return -1; } printf("JIT is %p\n", jit); LL...

...access with an OO-design in another language (D), e.g. map from the C API back up to a D API that closely resembles the original C++ API. Since I would like to have D (with its own exception system) to handle the IO, I need a new C API function (unless there is one and I haven't found it): LLVMBool LLVMCreateMemoryBufferWithArray(const char* Array, char** OutMessage) As the name suggests, create a MemoryBuffer for use with LLVMParseBitcode so that one can parse bitcode already present in memory (e.g. use D's capibilities for loading files with its own exception system present, so it d...

...directly in the header, instead of a c/cpp file); That in turn means the compiler won't export a symbol for this function, making it inaccessible for other C compatible languages that use the shared library. Applying a visibiliy attribute of default to the functio i.e. changing static inline LLVMBool LLVMInitializeNativeTarget(void) { to __attribute__((visibility("default"))) static inline LLVMBool LLVMInitializeNativeTarget(void) { doesn't work because -fvisibility-inlines-hidden seems to get handed down from the top Makefile. The solution to this may be simple, but I cannot s...

...remove what is left of the pass from the source tree. However, there are a few C API functions for creating and managing the pass: /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */ void LLVMPassManagerBuilderSetDisableSimplifyLibCalls(LLVMPassManagerBuilderRef PMB, LLVMBool Value); /** See llvm::createSimplifyLibCallsPass function. */ void LLVMAddSimplifyLibCallsPass(LLVMPassManagerRef PM); Is it OK to remove these? Do I need to keep them? Or is there some sort of deprecation process? -- Meador

...retInst = LLVMBuildRet(builder, y); (void) retInst; LLVMDisposeBuilder(builder); LLVMLinkInJIT(); LLVMLinkInInterpreter(); LLVMInitializeNativeTarget(); LLVMDumpModule(module); /* Now run it! */ LLVMExecutionEngineRef jit = NULL; char *err; // LLVMBool result = LLVMCreateExecutionEngineForModule(&jit, module, &err); LLVMBool result = LLVMCreateJITCompilerForModule(&jit, module, 0, &err); if (result) { printf("Fail: %s\n", err); return -1; } printf("JIT is %p\n", jit); LLVMG...

...Support/raw_ostream.h" #include "llvm/IR/DiagnosticPrinter.h" #include <string> #include <iostream> using namespace llvm; using namespace std; int main() { // vars string Message; raw_string_ostream Stream(Message); DiagnosticPrinterRawOStream DP(Stream); LLVMBool Result; // create blank modules and contexts LLVMContext *ctx1 = new LLVMContext; Module* module1 = new Module("module1", *ctx1); LLVMContext *ctx2 = new LLVMContext; Module* module2 = new Module("module2", *ctx2); LLVMContext *ctx3 = new LLVMContext; Module...

...e tree. However, there are a few C API functions for > creating and managing > the pass: > > /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */ > void > LLVMPassManagerBuilderSetDisableSimplifyLibCalls(LLVMPassManagerBuilderRef > PMB, > > LLVMBool Value); > > /** See llvm::createSimplifyLibCallsPass function. */ > void LLVMAddSimplifyLibCallsPass(LLVMPassManagerRef PM); > > > Is it OK to remove these? Do I need to keep them? Or is there some > sort of deprecation process? I think you should try to keep them....

...nosticPrinter.h" > #include <string> > #include <iostream> > > using namespace llvm; > using namespace std; > > int main() { > // vars > string Message; > raw_string_ostream Stream(Message); > DiagnosticPrinterRawOStream DP(Stream); > LLVMBool Result; > // create blank modules and contexts > LLVMContext *ctx1 = new LLVMContext; > Module* module1 = new Module("module1", *ctx1); > LLVMContext *ctx2 = new LLVMContext; > Module* module2 = new Module("module2", *ctx2); > LLVMContext *ctx3 = ne...

...// Remove dead fns and globals. + PM.add(createConstantMergePass()); // Merge dup global constants + } + addExtensionsToPM(EP_OptimizerLast, PM); } inline PassManagerBuilder *unwrap(LLVMPassManagerBuilderRef P) { @@ -458,5 +583,6 @@ LLVMBool RunInliner) { PassManagerBuilder *Builder = unwrap(PMB); PassManagerBase *LPM = unwrap(PM); - Builder->populateLTOPassManager(*LPM, Internalize != 0, RunInliner != 0); + Builder->populateIPOPassManager(*LPM, Internalize != 0, RunInliner != 0); + Builder->populatePostIPOPM(*LPM);...

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only