search for: libfunc

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

...Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > > Hi, > > I think that might be difficult to detect. If you wanted to force > this behaviour in your own toolchain, you could just use "-mllvm > -force-attribute=malloc:readnone" on the clang command line? This is unlikely to be desirable...

...{ PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B) { Value *Ret = NULL; if (UnsafeFPShrink && Callee->getName() == "pow" && TLI->has(LibFunc::powf)) { UnaryDoubleFPOpt UnsafeUnaryDoubleFP(true); Ret = UnsafeUnaryDoubleFP.callOptimizer(Callee, CI, B); } [...] if (Op2C->isExactlyValue(0.5)) { // Expand pow(x, 0.5) to (x == -infinity ? +infinity : fabs(sqrt(x))). // This is faster than calling pow, and...

...(UnsafeFPShrink) {}**** > > virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> > &B) {**** > > Value *Ret = NULL;**** > > if (UnsafeFPShrink && Callee->getName() == "pow" &&**** > > TLI->has(LibFunc::powf)) {**** > > UnaryDoubleFPOpt UnsafeUnaryDoubleFP(true);**** > > Ret = UnsafeUnaryDoubleFP.callOptimizer(Callee, CI, B);**** > > }**** > > ** ** > > [...]**** > > ** ** > > if (Op2C->isExactlyValue(0.5)) {**** > > //...

TLDR: Figuring out whether a declaration is a TLI LibFunc is slow.  We hammer that path in CGP.  I'm proposing storing the ID of a TLI LibFunc in the same IntID field in Function we use for IntrinsicID to make that fast. Looking into a compile time issue during codegen (LLC) for a large IR file, I came across something interesting.  Due to the presen...

Hi, GlobalsAA, during propagation of mod-ref behavior in the call graph, looks at library functions (in GlobalsAAResult::AnalyzeCallGraph: F->isDeclaration() check), for attributes, and if the function does not have the onlyReadsMemory attribute set, forgets it. I noticed that library functions such as malloc/realloc do not have the attributes doesNotAccessMemory or onlyReadsMemory

Hi all, Background I've been working on adding the necessary support to LLVM for clang to be able to support the STDC FENV_ACCESS pragma, which basically allows users to modify rounding mode at runtime and depend on the value of floating-point status flags or to unmask floating point exceptions without unexpected side effects. I've committed an initial patch (r293226) that adds

On 11 May 2017 at 18:30, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I note that on your bug that you have stated that the branch is faster than > the conditional move. Faster code is a side effect of the fix in this > particular case. On the contrary: the faster code is pretty much the only reason this can happen before the rest of the FENV support lands.

Hi James, Thank you for the response. I understand the concern about malloc/free hooks. Could we detect that a program has setup malloc hooks (assuming we're in a whole program compilation) and make assumptions (such as onlyAccessesArgMem()) when the program hasn't setup malloc hooks? Using a command line flag could be one option too. I'm currently working on a program where having

Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the

...cpp (revision 260011) +++ lib/Transforms/Utils/BuildLibCalls.cpp (working copy) @@ -52,6 +52,28 @@ return CI; } +Value *llvm::emitStrNLen(Value *Ptr, Value *MaxLen, IRBuilder<> &B, + const DataLayout &DL, const TargetLibraryInfo *TLI) { + if (!TLI->has(LibFunc::strlen)) + return nullptr; + + Module *M = B.GetInsertBlock()->getModule(); + AttributeSet AS[2]; + AS[0] = AttributeSet::get(M->getContext(), 1, Attribute::NoCapture); + Attribute::AttrKind AVs[2] = { Attribute::ReadOnly, Attribute::NoUnwind }; + AS[1] = AttributeSet::get(M->getC...

...-Andy > > > > > > *From:* Michael Clark [mailto:michaeljclark at mac.com] > *Sent:* Wednesday, May 10, 2017 7:59 PM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* FENV_ACCESS and floating point LibFunc calls > > > > Hi Andy, > > > > I’m interested to try out your patches… > > > > I understand the scope of FENV_ACCESS is relatively wide, however I’m > still curious if you managed to figure out how to prevent the > SelectionDAGLegalize::ExpandNode() FP_TO_U...

...tel at rotateright.com] > *Sent:* Thursday, May 11, 2017 2:06 PM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* Michael Clark <michaeljclark at mac.com>; llvm-dev < > llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] FENV_ACCESS and floating point LibFunc calls > > > > Sounds like the select lowering issue is definitely separate from the FENV > work. > > Is there a bug report with a C or IR example? You want to generate compare > and branch instead of a cmov for something like this? > > > int foo(float x) { > if...

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Ta...

...et/TargetLibraryInfo.h and added it to simplifylibcalls. TargetLibraryInfo doesn't handle all the libcalls that SimplifyLibCalls handles yet, but it should provide a starting point for iprintf: just add an iprintf enum to TargetLibraryInfo and make your transformation predicated on TLI->has(LibFunc::iprintf). It would be great to see this go into mainline, -Chris

...trlen(CallInst *CI, BasicBlock::iterator &BBI, > AliasAnalysis *AA, MemoryDependenceResults *MD, > const DataLayout &DL, const TargetLibraryInfo *TLI, > InstOverlapIntervalsTy &IOL, > DenseMap<Instruction *, size_t> *InstrOrdering) { > > // Must be a strlen. > LibFunc Func; > Function *Callee = CI->getCalledFunction(); > if (!TLI->getLibFunc(*Callee, Func) || !TLI->has(Func) || > Func != LibFunc_strlen) > return false; > > Value *Dst = CI->getOperand(0); > Instruction *UnderlyingPointer = > dyn_cast<Instruction>(GetUnder...

...%call1 } static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults *MD, const DataLayout &DL, const TargetLibraryInfo *TLI, InstOverlapIntervalsTy &IOL, DenseMap<Instruction *, size_t> *InstrOrdering) { // Must be a strlen. LibFunc Func; Function *Callee = CI->getCalledFunction(); if (!TLI->getLibFunc(*Callee, Func) || !TLI->has(Func) || Func != LibFunc_strlen) return false; Value *Dst = CI->getOperand(0); Instruction *UnderlyingPointer = dyn_cast<Instruction>(GetUnderlyingObject(Dst, DL)); if (!UnderlyingP...

...trlen(CallInst *CI, BasicBlock::iterator &BBI, > AliasAnalysis *AA, MemoryDependenceResults *MD, > const DataLayout &DL, const TargetLibraryInfo *TLI, > InstOverlapIntervalsTy &IOL, > DenseMap<Instruction *, size_t> *InstrOrdering) { > > // Must be a strlen. > LibFunc Func; > Function *Callee = CI->getCalledFunction(); > if (!TLI->getLibFunc(*Callee, Func) || !TLI->has(Func) || > Func != LibFunc_strlen) > return false; > > Value *Dst = CI->getOperand(0); > Instruction *UnderlyingPointer = > dyn_cast<Instruction>(GetUnder...

...ayout &DL, const TargetLibraryInfo *TLI, >>>> InstOverlapIntervalsTy &IOL, >>>> DenseMap<Instruction *, size_t> *InstrOrdering) { >>>> >>>> // Must be a strlen. >>>> LibFunc Func; >>>> Function *Callee = CI->getCalledFunction(); >>>> if (!TLI->getLibFunc(*Callee, Func) || !TLI->has(Func) || >>>> Func != LibFunc_strlen) >>>> return false; >>>> >>>> Value *Dst = CI->getOpe...

I'm trying to figure out exactly how the intrinsics/libc/libm work in llvm. For example, this code return user defined function: float acos(float x, float y) { return x+y; } float a; void foo(float b, float c) { a = acos(b, c); } But this code returns llvm.intrinsic: float acos(float, float); float a; void foo(float b, float c) { a = acos(b, c); } float acos(float x, float y) {