similar to: [LLVMdev] Proposal to merge SimplifyLibCalls into InstCombiner

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

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

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 IR-level attribute instead of a target-dependent attribute because it's used during IR modification and not code

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

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 write. They range

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

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 *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)

Sorry - I misread your example and the problem. I see now where LibCallSimplifier creates the select...but we are immediately erasing that select with the code from the godbolt example. Does the real motivating case have no uses of the pow() result value? On Mon, Sep 14, 2020 at 1:03 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, I mean just bail out on the transform in >

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.

Hi, one of the greendragon bots is flaky due to mmap_stress.cc in compiler-rt. In the last two days this bot failed three times (and recovered) due to thhe mmap_stress.cc test in compiler-rt: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9557/testReport/ http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9551/testReport/

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

On Mon, Sep 14, 2020 at 12:45 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, that looks like a bug. The transform is ok in general for negative > numbers, but -Inf is a special-case for pow(), right? > If so, we probably need an extra check of the input with > "isKnownNeverInfinity()". > There is an extra check there already, but it uses

Ok. So it seems CI->eraseFromParent() removed the old instruction and the new one is inserted right after this one in the inner function in the case of printf->puts. There is another line CI->repalceAllUsesWith(Result). I think this line could also do the replacement besides inserting the new one in the inner function. What's the difference of these 2 replacement methods? Also

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() { >>>

The transformation in LibCallSimplifier::replacePowWithSqrt with respect to -Inf uses a select instruction, which based on the observed behaviour, incorporates the side effects of the unchosen branch. This means that (for pow) a call to sqrt(-Inf) is materialized. Such a call is specified as having a domain error (C17 subclause 7.12.7.5) since the operand is less than zero. Contrast this with

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 IR-level attribute instead of a target-dependent attribute because it's used during IR modification and not code generation. -bw -------------- next part -------------- A non-text attachment was scrubbed...

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>

I have hit a fairly isolated practical issue deploying the new PM, but it does point to a latent theoretical issues as well. I see various ways to address it, but want feedback from others before moving forward. The issue is that we can introduce out-of-thin-air calls to known library functions (`SimplifyLibCalls`, etc). These can be introduced in function passes (`InstCombine` in particular) and