search for: libcallsimplifier

...`InstCombiner` visitor framework is proposed. Sounds like the right high level design. > The following three sections specify a proposal for how the work will be broken > down. In a way they specify milestones. > > Extend test coverage > -------------------- +1 > Create new `LibCallSimplifier` class > ------------------------------------ > > 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::tryOptimizeC...

...oor, cell, round, rint, nearbyint, ffs, ffsl, ffsll, abs, labs, llabs, isdigit, isascii, toascii, sprintf, print, fwrite, fputs, fprintf, puts. Test cases that exercise the library call folders for each of these functions should be present. Any missing test cases will be added. Create new `LibCallSimplifier` class ------------------------------------ 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 implementati...

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

...ownNeverInfinity()" returns true. > If there are other errno divergences for edge case values, we may need to > check other conditions. > > On Sat, Sep 12, 2020 at 9:37 PM Hubert Tong via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 d...

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

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

...ntation 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 for the attribute to be on function bodies, not on proto...

...ncept 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 for the attribute to be on function bodies, not on prototypes. -Chris

...ver, if we >> get all the way to code gen, then we failed to find a length, so we remove them. > > Thanks for the explanation. As a part of the merger I really want > `SimplifyFortifiedLibCalls` to go away as well, since the fortified > library call folding is being rolled into `LibCallSimplifier`. I will > look at applying `LibCallSimplifier` to the CGP case as well (the conditions > for when it is OK to fold is slightly different for CGP). Ok, please just tackle this as a follow-on step. Thanks Meador! -Chris

...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 for the attribute to be on functi...

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

...> > 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 for the attribute to be on...

...st of 2.b) and 2.c) are similar and 2.c) seems to be more flexible. So, I guess we don't really have to tie this discussion with "letting LV emit widened math call instead of VECLIB", even though I strongly favor that than LV emitting VECLIB calls. @Davide, in D19544, @spatel thought LibCallSimplifier has relevance to this legalization topic. Do you know enough about LibCallSimiplifer to tell whether it can be extended to deal with 2.b) or 2.c)? If we think 2.b)/2.c) are right enough directions, I can clean up what we have and upload it to Phabricator as a starting point to get to 2.b)/2.c). C...

...een start of function and gp pointer into GOT therefore any relocations against it do not require dynamic relocation. o *edit*: llvm-revision.src/lld/trunk/ELF/Writer.cpp o *edit*: llvm-revision.src/lld/trunk/test/ELF/mips-gp-disp.s * Commit *257491* by *spatel:* [LibCallSimplifier] use instruction-level fast-math-flags to transform pow(exp(x)) calls See also: http://reviews.llvm.org/rL255555 http://reviews.llvm.org/rL256871 http://reviews.llvm.org/rL256964 http://reviews.llvm.org/rL257400 http://reviews.llvm.org/rL257404 http://reviews.llvm.org/rL257414...

On Wed, Sep 26, 2018 at 9:32 AM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> >> This is the first time I'm looking at foldShuffledBinop(...), so maybe a >> naive question, but why not do similar shuffle canonicalizations on unary >> (or

.... So, I guess we don’t really have to tie this >> >> discussion with “letting LV emit widened math call instead of VECLIB”, >> even though I strongly favor that than LV emitting >> >> VECLIB calls. >> >> >> >> @Davide, in D19544, @spatel thought LibCallSimplifier has relevance to >> this legalization topic. Do you know enough about >> >> LibCallSimiplifer to tell whether it can be extended to deal with 2.b) or >> 2.c)? >> >> >> >> If we think 2.b)/2.c) are right enough directions, I can clean up what we >&g...

...2.c) seems to be more > flexible. So, I guess we don’t really have to tie this > > discussion with “letting LV emit widened math call instead of VECLIB”, > even though I strongly favor that than LV emitting > > VECLIB calls. > > > > @Davide, in D19544, @spatel thought LibCallSimplifier has relevance to > this legalization topic. Do you know enough about > > LibCallSimiplifer to tell whether it can be extended to deal with 2.b) or > 2.c)? > > > > If we think 2.b)/2.c) are right enough directions, I can clean up what we > have and upload it to Phabricator...

...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 for the at...

Hi, I want an efficient way to implement function pow in LLVM instead of invoking pow() math built-in. For algorithm part, I am clear for the logic. But I am not quite sure for which parts of LLVM should I replace built-in pow with another efficient pow implementation. Any comments and feedback are appreciated. Thanks! -- Wei Ding -------------- next part -------------- An HTML attachment was

...have to tie this > > discussion with “letting LV emit widened math call instead > of VECLIB”, even though I strongly favor that than LV emitting > > VECLIB calls. > >   > > @Davide, in D19544, @spatel thought LibCallSimplifier has > relevance to this legalization topic. Do you know enough about > > LibCallSimiplifer to tell whether it can be extended to > deal with 2.b) or 2.c)? > >   > > If we think 2.b)/2.c) are right enough directions,...