similar to: [LLVMdev] Implementing platform specific library call simplification

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

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 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 Feb 24, 2011, at 12:41 AM, John Criswell wrote: >>>> At the moment I've got this working locally by adding 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?

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.

Hi, I have finished migrating all of the simplify-libcalls pass functionality into instcombine and functionattrs. Now I am ready to completely to 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

On Thu, Feb 24, 2011 at 7:32 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 24, 2011, at 12:41 AM, John Criswell wrote: >> Sorry to jump into something midstream, but I just happened to read the >> above paragraph and thought I should comment.  Adding a boolean argument >> to a pass's constructor method is one of the things I have learned not >> to

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

This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this

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

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 Meador, > I have finished migrating all of the simplify-libcalls pass > functionality into instcombine > and functionattrs. Now I am ready to completely to 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 */

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

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 Feb 18, 2013, at 4:45 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 18, 2013, at 1:54 PM, Bill Wendling <wendling at apple.com> wrote: > >> Hi LLVMites! >> >> This patch adds the 'nobuiltin' attribute to to LLVM. This is needed during LTO, which right now ignores this attribute and command line flag. I want to make this an

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

On Feb 18, 2013, at 4:49 PM, Bill Wendling <wendling at apple.com> wrote: >> Hi Bill, >> >> I think 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

And how about this one so as not to include a C specific header in llvm-backend (!!!) and not to have llvm-backend use a C specific flag (flag_no_builtin)? Index: gcc-4.2.llvm/gcc/c-opts.c =================================================================== --- gcc-4.2.llvm.orig/gcc/c-opts.c 2008-07-30 21:25:28.000000000 +0200 +++ gcc-4.2.llvm/gcc/c-opts.c 2008-07-30 21:26:17.000000000 +0200 @@

On Feb 18, 2013, at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 18, 2013, at 4:49 PM, Bill Wendling <wendling at apple.com> wrote: >>> Hi Bill, >>> >>> I think the concept of this patch makes sense, but the implementation does not. >>> >>> I have: >>> >>> void foo() { >>>