search for: simplifylibcalls

Hi All, I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` into `InstCombiner`. There is still an open question or two and I am sure there are parts that could be better specified, but this is good enough to discuss. Feedback is most welcome. Abstract ======== This proposal is an attack plan for PR11895 [1]. Currently within LLVM we have two passes t...

On Aug 1, 2012, at 9:49 PM, Meador Inge <meadori at codesourcery.com> wrote: > Hi All, > > I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` > into `InstCombiner`. There is still an open question or two and I am sure > there are parts that could be better specified, but this is good enough to > discuss. Feedback is most welcome. Fantastic, I'm glad that you're looking to tackle this. > An design that combines th...

Hi Thomson, the new call to puts() is inserted right away, whereas the old call to printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If you browse the code a bit and backtrack the call stack to see what happens with the return value of PrintFOpt::OptimizeFixedFormatString(), you will stumble upon this segment in SimplifyLibCalls.cpp:1703ff.: // Try to optimize this call. Value *Result = LCO->OptimizeCall(CI...

I found that LLVM optimized the IR by replacing printf with puts. I wondered which pass did this optimization? And is it common that puts is faster (and some other metric) than printf? -- Thanks Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/08aa6c45/attachment.html>

On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > Hi,**** > > ** ** > > It looks like SimplifyLibCalls has a tendency to emit calls to libm > functions without checking with TLI whether these calls are available.**** > > For example, PowOpt has this code:**** > > ** ** > > struct PowOpt : public UnsafeFPLibCallOptimization {**** > > PowOpt(bool UnsafeFPShrink) : > Uns...

Hi, I would like to propose that when available, if a C builtin function has an equivalent llvm intrinsic, that the intrinsic be the preferred form. The equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls should replace calls with the intrinsic. For context, this came up on an old review thread: http://reviews.llvm.org/D5896 There are a few motivations for this: 1. Intrinsics have additional properties that help optimizations. They are more widely considered by optimization passes, such as bein...

Hi, It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available. For example, PowOpt has this code: struct PowOpt : public UnsafeFPLibCallOptimization { PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOp...

...fy-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 us...

I've been working on some basic library call optimizations, the SimplifyLibCalls pass (lib/Transforms/IPO/SimplifyLibCalls.cpp). Tonight I conjured up a list of the potential libcall simplifications that could be done. There's a lot of them. I could use some help if anyone wants to pitch in. The individual optimizations are self-contained and fairly straight forward to wri...

Hello, Can somebody review my patch? https://reviews.llvm.org/D45736 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/8f0570ae/attachment.html>

On Aug 3, 2012, at 12:56 PM, Meador Inge <meadori at codesourcery.com> wrote: >>> An option for enabling/disabling library call simplification in `InstCombiner` >>> will be available. For backwards compatibility perhaps it should remain >>> '-simplify-libcalls'. The `NumSimplified` and `NumAnnotated` statistics shall >>> be added to

...o 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 el...

...contained `LibCallSimplifier` class will be created. An instance >> of the class will be instantiated when running the `InstCombiner` pass. It's >> folding functionality will be invoked from `InstCombiner::tryOptimizeCall` and >> the implementation will be table-driven like `SimplifyLibCalls`. All of the >> existing fortified library call simplifiers will be migrated to this new class >> at this step. > > Ok, the idea is that other general parts of the compiler can use the LibCallSimplifier > interface as well? That makes sense to me. Yup, that's it. >&...

To this day, we still do too little when it comes to optimizing well known library calls. Given that various libraries, especially the C/C++ standard library, are relatively clear defined, and LLVM has all the infrastructure already in place, e.g., SimplifyLibCalls.cpp, it seems odd that we still miss so many optimization opportunities. To show how easy it is, and how much impact it can have, I crafted a very simple, yet very effective patch which will hopefully only be the first of its kind. The attached twelve line addition to SimplifyLibCalls.cpp provide...

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

...k the concept of this patch makes sense, but the implementation does not. > > I have: > > void foo() { > printf("hello\n"); > } > > and I build with -fno-builtin-puts. If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf: > > Value *LibCallSimplifier::optimizeCall(CallInst *CI) { > + Function *F = CI->getCalledFunction(); > + if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0; > return Impl->optimizeCall(CI); > } > > In the context of LTO, it makes sense...

...hods? Also thanks for your reminder of CC the mailing list. -Thomson On Mon, Jun 18, 2012 at 4:08 PM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Thomson, > > the new call to puts() is inserted right away, whereas the old call to > printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If > you browse the code a bit and backtrack the call stack to see what > happens with the return value of PrintFOpt::OptimizeFixedFormatString(), > you will stumble upon this segment in SimplifyLibCalls.cpp:1703ff.: > > // Try to optimize this call. > Value *Res...

...es sense, but the implementation does not. >> >> I have: >> >> void foo() { >> printf("hello\n"); >> } >> >> and I build with -fno-builtin-puts. If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf: >> >> Value *LibCallSimplifier::optimizeCall(CallInst *CI) { >> + Function *F = CI->getCalledFunction(); >> + if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0; >> return Impl->optimizeCall(CI); >> } >> >> In the...

Chris and all, IMHO I think SimplifyLibcall and similar might be provided by rather clang (and frontends), than LLVM itself. Frontends might know better than LLVM (as backend infrastructure). ...Takumi

Hi, LLVM optimizer seems to leave "call exit" instruction in "main" function but it could be replaced by a return instruction. Any reason why leave it as is or this simple optimization could be implemented e.g. in SimplifyLibCalls? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180403/01d88af9/attachment.html>