search for: createsimplifylibcallspass

...case right now, but in the meantime, I'd like for you to try something. This should work around the problem that you're having (as well as verify that I understand the problem): Go into your LLVM source tree and comment out the following line in llvm/tools/gccas/gccas.cpp: addPass(PM, createSimplifyLibCallsPass()); // Library Call Optimizations Rebuild gccas. Then, try to build the LLVM GCC frontend again. Please email the llvmdev list and let us know if it works. In the meantime, I will continue to try to get a reduced test case and either fix the bug or hand it off to Reid (the author of the C...

...om 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

On Tue, 28 Jun 2005, John Criswell wrote: > addPass(PM, createSimplifyLibCallsPass()); // Library Call Optimizations > > Rebuild gccas. Then, try to build the LLVM GCC frontend again. Please email > the llvmdev list and let us know if it works. > > In the meantime, I will continue to try to get a reduced test case and either > fix the bug or hand it off...

...code to the > simplify-libcalls pass. However this will break on targets where > iprintf() isn't available. Is there a sensible place to add information > about which library functions are available for a particular target? I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. Longer term, I'd like to introduce a simple interface (via TargetRegistry) for exposing target libcall info. This would be useful to elimin...

...simplify-libcalls pass. However this will break on targets where >> iprintf() isn't available. Is there a sensible place to add information >> about which library functions are available for a particular target? > > I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. > > Longer term, I'd like to introduce a simple interface (via TargetRegistry) for exposing target libcall info. This would be useful...

The newlib C library provides iprintf(), a restricted version of printf without support for floating-point formatting. I'd like to add an optimization which turns calls to printf() into calls to iprintf() if the format string has no floating point specifiers. At the moment I've got this working locally by adding code to the simplify-libcalls pass. However this will break on targets

...gInfo = 0; @@ -381,7 +383,7 @@ PM->add(createFunctionInliningPass()); // Inline small functions if (optimize > 2) PM->add(createArgumentPromotionPass()); // Scalarize uninlined fn args - if (!flag_no_builtin) + if (!flag_no_simplify_libcalls) PM->add(createSimplifyLibCallsPass()); // Library Call Optimizations PM->add(createInstructionCombiningPass()); // Cleanup for scalarrepl. PM->add(createJumpThreadingPass()); // Thread jumps.

...lify-libcalls pass. However this will break on targets where >>> iprintf() isn't available. Is there a sensible place to add information >>> about which library functions are available for a particular target? >> I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. Sorry to jump into something midstream, but I just happened to read the above paragraph and thought I should comment. Adding a boolean argumen...

On Jul 30, 2008, at 11:39 AM, Duncan Sands wrote: > On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: >> On x86-64 linux, in stage 2, I get: >> >> c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- >> prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- >> variadic-macros -Wno-overlength-strings -Wold-style-definition - >>

...============================ --- gcc/llvm-linker-hack.cpp (revision 84984) +++ gcc/llvm-linker-hack.cpp (working copy) @@ -80,7 +80,6 @@ llvm::createJumpThreadingPass(); llvm::createFunctionInliningPass(); llvm::createAlwaysInlinerPass(); - llvm::createRaiseAllocationsPass(); llvm::createSimplifyLibCallsPass(); llvm::createArgumentPromotionPass(); llvm::createDeadArgEliminationPass(); -------------- next part -------------- A non-text attachment was scrubbed... Name: RemoveRaiseAllocations.diff Type: application/octet-stream Size: 478 bytes Desc: not available URL: <http://lists.llvm.org/pi...

...ions 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. I guess LLVMAddSimplifyLibCallsPass can be changed to do nothin...

...plificationPass()); // Clean up after IPCP & DAE + PerModulePasses->add(createPruneEHPass()); // Remove dead EH info + + if (optimize > 1) { + PerModulePasses->add(createFunctionInliningPass()); // Inline small functions + PerModulePasses->add(createSimplifyLibCallsPass()); // Library Call Optimizations + + if (optimize > 2) + PerModulePasses->add(createArgumentPromotionPass()); // Scalarize uninlined fn args + + PerModulePasses->add(createRaisePointerReferencesPass());// Recover type information + } + + PerModulePasses-...

...PM->add(createFunctionInliningPass()); // Inline small > functions > if (optimize > 2) > PM->add(createArgumentPromotionPass()); // Scalarize > uninlined fn args > - if (!flag_no_builtin) > + if (!flag_no_simplify_libcalls) > PM->add(createSimplifyLibCallsPass()); // Library Call > Optimizations > PM->add(createInstructionCombiningPass()); // Cleanup for > scalarrepl. > PM->add(createJumpThreadingPass()); // Thread jumps.

...s pass. However this will break on targets where >>>> iprintf() isn't available. Is there a sensible place to add information >>>> about which library functions are available for a particular target? >>> I'd suggest adding a bool argument (HasIPrintf) to the createSimplifyLibCallsPass function and the pass constructor. Then clang (or whatever is setting up the pass manager) can query the appropriate target info to pass down this flag. > > Sorry to jump into something midstream, but I just happened to read the > above paragraph and thought I should comment. Adding a...

...-backend.cpp I see: if (optimize > 1) { if (flag_inline_trees > 1) // respect -fno-inline-functions PM->add(createFunctionInliningPass()); // Inline small functions if (flag_unit_at_a_time && !lang_hooks.flag_no_builtin()) PM->add(createSimplifyLibCallsPass()); // Library Call Optimizations if (optimize > 2) PM->add(createArgumentPromotionPass()); // Scalarize uninlined fn args } Shouldn't createFunctionInliningPass and createArgumentPromotionPass only be called if flag_unit_at_a_time is true? As far as I can see flag_u...

Hi Duncan & Tobi, Thanks a lot for your interest, and for pointing out differences in GIMPLE I missed. Attached is simplified test case. Is it good? Tobi, regarding runtime alias analysis: in KernelGen we already do it along with runtime values substitution. For example: <------------------ __kernelgen_main_loop_17: compile started ---------------------> Integer args substituted:

On 01/01/2013 02:45 PM, Duncan Sands wrote: > Hi Dmitry, > >> >> In our compiler we use a modified version LLVM Polly, which is very >> sensitive to >> proper code generation. Among the number of limitations, the loop region >> (enclosed by phi node on induction variable and branch) is required to >> be free >> of additional memory-dependent

...allelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::createBitcodeWriterPass(llvm::raw_ostream&) /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::TargetData::ID /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::createSimplifyLibCallsPass() /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::createLoopDependenceAnalysisPass() /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::CallGraphLinkVar /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Ass...

...cts/compiler/llvm-gcc/gcc/llvm-backend.cpp:299: error: `createPruneEHPass' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:303: error: `createFunctionInliningPass' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:305: error: `createSimplifyLibCallsPass' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:308: error: `createArgumentPromotionPass' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:311: error: `createTailDuplicationPass' was not declared in this scope /projects/c...