search for: callsite

...ation but I really can't see the easy way > to > > compare those instructions and again finish with reinvented (but working) > > wheel ;). > Ah, sorry. I missed that you're doing variadic calls, not casting > variadic function to definite ones. I think you can construct CallSite > and then iterate over the arguments grabbing their types and construct > function type after that. > So what do you think about that: // CallSites have equal signatures bool MSILWriter::cmpCallSite(CallSite A, CallSite B) { return (getCallSiteFType(A)==getCallSiteFType(B) &&...

LLVM (2.7 release version) provides 2 implementations for inlining function callsites: - InlineSimple.cpp (-inline): inline simple callsites according to its cost analysis - InlineAlways.cpp (-always-inline): inline all callsites that are marked with "always_inline" attribute. They are both subclasses of Inline.cpp that assumes the function's defin...

On Tue, Jul 27, 2010 at 7:46 AM, Chuck Zhao <czhao at eecg.toronto.edu> wrote: >  LLVM (2.7 release version) provides 2 implementations for inlining > function callsites: > > - InlineSimple.cpp (-inline):               inline simple callsites > according to its cost analysis > - InlineAlways.cpp (-always-inline):  inline all callsites that are > marked with "always_inline" attribute. > > They are both subclasses of Inline.cpp that as...

Hi, Artur > // CallSites have equal signatures > bool MSILWriter::cmpCallSite(CallSite A, CallSite B) { >   return (getCallSiteFType(A)==getCallSiteFType(B) && >     A.getAttributes()==B.getAttributes()); > } As it is impossible to honour argument attributes in MSIL I don't see why you should compa...

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance of the generated code without significant code size increases. We propose to generate synthetic function counts for non-PGO compilation and use the counts for boosting...

...about how AliasSetTracker merging AliasSet's when meet UnknownInst. When adding new pointer it looks for existing AliasSet's aliased with new pointer. And merging them together. It is ok for pointers: if %A mayalias %B and %B mayalias %C then %A mayalias %C. But the same logic when adding callsite is wrong ( findAliasSetForUnknownInst). Callsite may be known to readonly access one pointer and change the content of other pointer. Why to merge together two noalias pointers if they have some mod/ref relationships with common callsite? If modrefinfo(%A, %call1) == REF and modrefinfo(%B, %call1...

...passed on command line with a positive integer value of X. If X is 0, or this option is not specified, the Inliner does not create or perform any operations on the inline report, and there is no compile time overhead. Three main classes are used to implement the inline report: class InlineReportCallSite This class contains the inlining report information specific to a particular CallSite CS, including: (1) A bool indicating whether or not the CallSite was or was not inlined (2) An inlining reason indicating why the CallSite was or was not inlined (3) The inlining cost, outer inlining...

...iging in doxygen documentation but I really can't see the easy way to > compare those instructions and again finish with reinvented (but working) > wheel ;). Ah, sorry. I missed that you're doing variadic calls, not casting variadic function to definite ones. I think you can construct CallSite and then iterate over the arguments grabbing their types and construct function type after that. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 7/27/2010 12:40 PM, Devang Patel wrote: > On Tue, Jul 27, 2010 at 7:46 AM, Chuck Zhao<czhao at eecg.toronto.edu> wrote: >> LLVM (2.7 release version) provides 2 implementations for inlining >> function callsites: >> >> - InlineSimple.cpp (-inline): inline simple callsites >> according to its cost analysis >> - InlineAlways.cpp (-always-inline): inline all callsites that are >> marked with "always_inline" attribute. >> >> They are both subc...

...no other interesting aspect shared -- the interface itself just dispatches to specific instructions to be implemented. On the flip side, CallInst and InvokeInst have *massive* amounts of code shared and struggle to be effective due to being unable to share a base class in the type system. We have CallSite and a host of other complexity trying to cope with this, and honestly, it isn't doing such a great job. I propose we make "terminator-ness" a *property* of an instruction and take it out of the type system. We can build a handful of APIs to dispatch between instructions with this pro...

Hello, > So, looking for type of callee (not result, but function type!) you'll > obtain the > real "signature" of callee and if you'll strip all pointer cast you'll > obtain the "declaration" (=variadic) type of the callee. Maybe I misunderstood something but I just get the variadic declaration not the real "signature", like this: const

Hello, My team and I noticed that callsite hotness information is not preserved from compile to link step with LTO/thinLTO enabled. As a result, the link step inlining pass remains conservative when inlining callsites known to be hot (ie. without the 'HotCallSiteThreshold' which is set at 3000 by default). There are likely many cr...

...rough statepoints when posssible, except that the "devirtualization" is only a facade (i.e. we don't mutate the IR to change the statepoint to a direct call). We add some abstraction to the inlining utility functions to inline through something more general than a CallSite. 2. Introduce a new abstraction InlineSite (bikeshedding on the name is welcome). InlineSite sits on top of a CallSite and knows how to extract the semantic call out of a statepoint or a patchpoint (similar to the llvm::Statepoint class). The inliner and the call graph anal...

%294 = call float bitcast (float (float, float*)* @__gpu_modff to float ( float, i64)*)(float %293, i64 %preg.212.addr.0) as you may know, some gpu backends don't support function call. we need to make sure to inline all functions here. however, Inliner can not figure out that this is a valid callsite in this form. actually, it is. in C words, cast a function and then call should be treat as callsite, right? thanks, --lx -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150104/60734c2e/attachment.html>

...call is a troubling inconsistency that leaves > me unsure which results I can trust and which I cannot. Hi Ben, I just tested the example you gave, and get the same results--one set is empty, the other contains the expected single function. As Andrew mentioned, DSA handles indirect and direct callsites differently, and for direct callsites it's expected that the user simply looks at the function itself to determine what is called. In this example, we only track one callsite in test() since as far as alias analysis goes, the effects of both callsites are same, and we don't need to consid...

...gt; >> Functions in LLVM IR have a function_entry_count metadata that is >> attached in PGO compilation. By using the entry count together with the >> block frequency info, the compiler computes the profile count of call >> instructions based on which the hotness/coldness of callsites can be >> determined. Experiments have shown that using a higher threshold for hot >> callsites results in improved runtime performance of the generated code >> without significant code size increases. We propose to generate synthetic >> function counts for non-PGO compilat...

...Yiu <gyiu at ca.ibm.com> wrote: > >> Hi Teresa, >> >> Actually, enabling the new pass manager manually seems to have solved >> this issue, so this problem is only valid for the old pass manager. >> > > It should not be an issue in the old PM either - the callsite hotness is > passed via IR. > More precisely, the function entry counts are passed via IR. With the old PM, we don't have callsite hotness information, but callee's entry count is used to boost the threshold. > As David mentioned, the new PM inliner does a better job of updating...

...u to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were available from other passes. 2) To separate methods discovering interests. Various (optional) heuristics would be helpful. Also I will help to contribute above someday. I had been afraid to read the discussion http://llvm.org/bugs/show...

...etween a single-cycle instruction and a long latency instruction. Instead of using InstructionCount(BB)), we could use Sum_I(Weight(I)) where the summation is over all instructions I in B and Weight(I) represents the time it takes to execute instruction I. The dynamic instruction count of F into a callsite C after inlining InlinedDI(F, C) can be similary computed taking into account the instructions that are simplified due to inlining. The estimated speedup is Speedup(F, C) = (DI(F) - InlinedDI(F, C)) / DI(F) Speedup above a pre-determined threshold implies there is an expected benefit in inlining...

In order to detect whether CallSite is present in innermost loop, do I need to insert logic from LoopInfo pass for collecting loops, within a CallGraphSCC pass?   Is there any other approach for this?   Regards, Pankaj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...