similar to: [RFC] Canonicalize libcalls to intrinsics

On Feb 13, 2011, at 12:24 AM, Chris Lattner wrote: > On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: >> 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

On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: > 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. Cool, ok. I can see how this would be very useful for a

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

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 that are used to

Hi Paul, > I am working on a pass to convert lib calls to intrinsic calls as discussed here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html this whole area is a little confusing. If you can recognize a libcall as being equivalent to an intrinsic, you could indeed turn it into an intrinsic, but on the other hand you could just directly do on it the IR transforms you want

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

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,

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > Hello, > > my target has libcall support for long long shifts. I already have the > following lines in my Lowering constructor: > >   setLibcallName(RTLIB::SHL_I64, "__llshl"); >   setLibcallName(RTLIB::SRL_I64, "__llshru"); >  

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

On 2/24/2011 1:21 AM, Chris Lattner wrote: > On Feb 13, 2011, at 12:24 AM, Chris Lattner wrote: > >> On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: >>> 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

On 08/02/2012 11:11 AM, Chris Lattner wrote: >> A new self-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

On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++

On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: > looks like some lines got moved, fixed on mainline, thanks. Not really fixed :-) Please commit this: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92749) +++ TEST.libcalls.Makefile (working copy) @@ -23,10 +23,10 @@

On Jan 5, 2010, at 6:22 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: >> 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any >> ideas about what is going wrong here? > > No idea why this stuff was there... looks like some lines got moved, fixed on mainline, thanks. -Chris >

Doh, thanks, done. -Chris On Jan 5, 2010, at 11:27 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: >> looks like some lines got moved, fixed on mainline, thanks. > > Not really fixed :-) Please commit this: > > Index: TEST.libcalls.Makefile > =================================================================== > ---

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

Hi, Looks like LLVM inserts a call __bzero even if my code never does so: libclamav JIT: Attempt to call external function __bzero libclamav JIT: *** FATAL error encountered during bytecode generation It turns out this is because Codegen has this: const char *X86Subtarget::getBZeroEntry() const { // Darwin 10 has a __bzero entry point for this purpose. if (getDarwinVers() >= 10)

On Tue, Jan 05, 2010 at 11:42:10AM -0800, Chris Lattner wrote: > Doh, thanks, done. LOL. Next patch should be titled 'really really really fix this' :-) Please apply the last part of the diff, too: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92757) +++ TEST.libcalls.Makefile (working copy) @@

This is what I get while trying to run 'make TEST=libcalls' in the top dir of test-suite: make[1]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource' make[2]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource/UnitTests' make[3]: Entering directory

Hi, I am working on a pass to convert lib calls to intrinsic calls as discussed here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html In my first attempt I created a FunctionPass that uses CallInst::setCalledFunction to replace the callee with the appropriate intrinsic (using Intrinsic::getDeclaration). After the pass runs I get an assertion from CallGraphSCCPass: