search for: targetlibraryinfo

Hello; I was trying to use the computeArraySize() function from the MemoryBuiltins.cpp file. It requires two arguments DataLayout *TD and const TargetLibraryInfo *TLI. Can anyone tell me how to get the TargetLibraryInfo? I am getting the DataLayout using: DataLayout *TD; TD = new DataLayout(&M); I hope that's the right way of getting it. Thanks a lot; -- Arnamoy Bhattacharyya Athabasca Hall 143 Department of Computing Science - University of A...

...le-output` hits a bunch of asserts in the LazyCallGraph. The problem here is that `argpromotion` turns a normal looking function `i8* @access({ i8* }* %arg, i64)` and turn it into a magical function `i8* @access(i8* %arg, i64)`. This latter signature is the POSIX `access` function that LLVM's `TargetLibraryInfo` knows magical things about. Because *some* library functions known to `TargetLibraryInfo` can have *calls* to them introduced at arbitrary points of optimization (consider vectorized variants of math functions), the new pass manager and its graph to provide ordering over the module get Very Unhap...

...39;d like to introduce a simple interface (via TargetRegistry) for exposing target libcall info. This would be useful to eliminate the HAVE_FLOORF etc #defines in simplifylibcalls, which break cross compilation. Hi Richard, Just to close the loop on this, I went ahead and added a new llvm/Target/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)....

...> DominanceFrontierAnalysis: Stores no pointers to other analyses. > (uses DominatorTreeAnalysis for "recalculate" though). > LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no > pointers. > LazyValueAnalysis: Stores pointers to AssumptionCache, TargetLibraryInfo, > DominatorTree. > DependenceAnalysis: Stores pointers to AliasAnalysis, ScalarEvolution, > LoopInfo > MemoryDependenceAnalysis: Stores pointers to AliasAnalysis, > AssumptionCache, TargetLibraryInfo, DominatorTree > MemorySSAAnalysis: Stores pointers to AliasAnalysis, DominatorT...

...are defined as static. The common problem when we include this and only use few function, compiler throw warning for unused functions. i.e. > llvm/include/llvm/Transforms/Utils/VectorUtils.h:102:1: warning: > 'llvm::Intrinsic::ID llvm::getIntrinsicIDForCall(llvm::CallInst*, const llvm::TargetLibraryInfo*)' > defined but not used [-Wunused-function] > getIntrinsicIDForCall(CallInst *CI, const TargetLibraryInfo *TLI) { > ^ Any specific reason, why these function are defined as static ? If not, can we make these as non-static functions, by moving them to separate cpp file (i.e. &quo...

...; can check this. >>> >>> b) For many analyses that might trigger this, I think we have a simpler >>> option. If the analysis is *immutable* for any reason -- that is, it >>> overrides its invalidate routine to always return "false" the way >>> TargetLibraryInfo should (although I'm not sure it does currently), we >>> shouldn't need to do this as it shouldn't be getting cleared out. Does this >>> make sense? Do others see anything I'm missing with that approach? >>> >>> 2. The AnalysisManager must do a so...

..., LI, DT, TLI, TTI, AC, ORE, VF.Width, IC, > &LVL, &CM); > > If we imagine that over time it evolves such that 50% of the variables have been renamed to camelBack versions of the type names, then it will look like this: > > InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI, > assumptionCache, ORE, vectorizationFactor.Width, IC, > &loopVectorizationLegality, &CM); Hold on... The change from UpperCamel to lowerCamel should be separate from going from X to somethingOtherName. It seems like in this example, TLI is changed to targetLibraryInfo...

...nverted to the new PM. I was trying it out on test-suite and SPEC2006. Yay! This email is about one issue that I ran into testing the pipeline on test-suite. The issue arose in the wild as an interaction between lcssa and gvn. But the issue is extremely general. What happened is that BasicAA uses TargetLibraryInfo. If it makes a change, then LCSSA marks BasicAA as preserved (if it made no change, it would preserve all). The new PM then invalidates everything not marked as preserved by LCSSA. So it does not invalidate BasicAA but it does invalidate TargetLibraryInfo. Now BasicAA is holding dangling pointers t...

...ding a boolean argument > to a pass's constructor method is one of the things I have learned not > to do. If I ever give a "How Not to Write an LLVM Pass" talk, this will > be one of the things in the list. FWIW, the patch didn't do that. SimplifyLibcalls depends on TargetLibraryInfo, which is an analysis pass. -Chris

I'm trying to fix a longstanding bug with library function calls on platforms where int is passed sign-extended in a register (it badly affects SystemZ, and has a chance of affecting PowerPC64, SPARC64, MIPS64 as well). The problem is that, on these platforms, C int corresponds to a "i32 signext" parameter, but all LLVM passes inserting library calls currently use just

...intrinsic, ...) "__xx_acos()" when it sees it. It sounds like you also want to recognize and optimize these calls. That involves (pre-CodeGen) IR-level optimizations. No, I don't think that's supported today without changing LLVM (see the list in my first email). > 3) change TargetLibraryInfo for functions that aren't covered in solutions 1 > and 2 (so that they can also be optimized) > > I must be missing something, I'm just not sure what it is. > > Thanks, > > Ryan > > > On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <ryta1203 at gmail.com> wro...

Hi all, i hope to get the MemoryLocation for argument %1 in a CallInst like "call void @function(i32* %1)", and i found an interface "getForArgument()" which seems available for this. However, i don't know how to correcly fill the 3rd argument TargetLibraryInfo in my own code and can't find an example in google. Does anybody know how to do it? Or some other advice for find the correct memory location more conveniently? Thank you very much! MemoryLocation <http://llvm.org/docs/doxygen/html/classllvm_1_1MemoryLocation.html> MemoryLocation::getF...

While this is target information, it isn't actually part of the target today and doesn't use any part of the target code. Maybe some day we can use a target hook to initialize the data structures, but even then I feel like this really belongs in the core analysis library. Would there be any objections to just moving it into Analysis? Doing this would remove a seriously ugly layering

...in the LazyCallGraph. > > > > The problem here is that `argpromotion` turns a normal looking function > `i8* @access({ i8* }* %arg, i64)` and turn it into a magical function `i8* > @access(i8* %arg, i64)`. This latter signature is the POSIX `access` > function that LLVM's `TargetLibraryInfo` knows magical things about. > > > > Because *some* library functions known to `TargetLibraryInfo` can have > *calls* to them introduced at arbitrary points of optimization (consider > vectorized variants of math functions), the new pass manager and its graph > to provide order...

...ument >> to a pass's constructor method is one of the things I have learned not >> to do.  If I ever give a "How Not to Write an LLVM Pass" talk, this will >> be one of the things in the list. > > FWIW, the patch didn't do that.  SimplifyLibcalls depends on TargetLibraryInfo, which is an analysis pass. However, TargetLibraryInfo does take a target triple (not a bool though) as constructor argument, defaulting to all-unknown. Maybe instead of being an ImmutablePass it should be a ModulePass so it can use Module::getTargetTriple() in runOnModule()? That should make it m...

In the first code I see a 'tail call @acos', in the second code I see a tail call @llvm.acos.f32'. (sorry, there should be only one input for acos, I've been trying many libm/libc functions). Not sure why it's called TargetLibraryInfo if it's not in target specific code? It seems that ALL targets use this code, making it generic. Am I missing something here? Basically you're saying if I changed/added the XXXacos in TargetLibraryInfo::hasOptimizedCodeGen then the ConstantFolding (and other opts) could then opt for this l...

...dev wrote: > >> On Oct 26, 2017, at 8:14 PM, Chandler Carruth via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> One alternative that seems appealing but doesn't actually help would >> be to make `TargetLibraryInfo` ignore internal functions. That is how >> the C++ spec seems to handle this for example (C library function >> names are reserved only when they have linkage). But this doesn't >> work well for LLVM because we want to be able to LTO an internalized >> C library. So...

...a look up of that (like most other sections of the >> core >> >> > code >> >> > do, ie have the tablegen or ISelLowering specify the libs etc..) >> >> >> >> I agree it's not the best place, but one difference is that >> >> TargetLibraryInfo is much more about OSes than architectures. >> >> >> >> > I'm not sure I follow about the RTLIB, I'm able to use an intrinsic >> for >> >> > floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and still use >> RTLIB >> >> &g...

...ple) because then they need to be manually lowered. Thanks, Ryan On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Not sure why it's called TargetLibraryInfo if it's not in target specific > > code? It seems that ALL targets use this code, making it generic. Am I > > missing something here? > > Some of the names can vary by platform, for example ARM sometimes has > __aeabi_memcpy instead of memcpy > > > ps. The spec als...

...ominanceFrontierAnalysis: Stores no pointers to other analyses. > (uses DominatorTreeAnalysis for "recalculate" though). > LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no > pointers. > LazyValueAnalysis: Stores pointers to AssumptionCache, > TargetLibraryInfo, DominatorTree. > DependenceAnalysis: Stores pointers to AliasAnalysis, > ScalarEvolution, LoopInfo > MemoryDependenceAnalysis: Stores pointers to AliasAnalysis, > AssumptionCache, TargetLibraryInfo, DominatorTree > MemorySSAAnalysis: Stores pointers to AliasAnalysis, DominatorTree...