search for: ibaev

...e this info topologically over the call graph, how representative will be the info if one just wants to use in a comparative sense ? -Dibyendu Sent from my Windows Phone ________________________________ From: Xinliang David Li<mailto:xinliangli at gmail.com> Sent: ‎12/‎27/‎2014 10:05 AM To: ibaev at codeaurora.org<mailto:ibaev at codeaurora.org> Cc: llvmdev<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] How to use BlockFrequency in inter-procedural context? On Fri, Dec 26, 2014 at 7:12 PM, <ibaev at codeaurora.org<mailto:ibaev at codeaurora.org>> wrote: The...

The BlockFrequency analysis has been useful for machine block placement, register allocation and other function-level optimizations. How could we extend it for use in an inter-procedural (whole-program) context? For example, if we would like to compare the hotness of two call sites in different functions, or calculate the hotness of two global variables referenced in multiple functions. If the

...--paulr > >   > > *From:* vsk at apple.com <vsk at apple.com> *On Behalf Of * Vedant Kumar > *Sent:* Friday, February 7, 2020 3:26 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* David Blaikie <dblaikie at gmail.com>; nikola.prica at rt-rk.com; ibaev at cisco.com; asowda at cisco.com; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] Enabling debug entry value production by default > >   > > The actual DWARF emission for call site parameters is gated inside of DwarfDebug::constructCallSiteEntryDIEs by `tuneForGDB() || tune...

...Kumar via llvm-dev > Sent: Friday, February 7, 2020 2:04 PM > To: David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> > Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; nikola.prica at rt-rk.com <mailto:nikola.prica at rt-rk.com>; ibaev at cisco.com <mailto:ibaev at cisco.com>; asowda at cisco.com <mailto:asowda at cisco.com> > Subject: Re: [llvm-dev] Enabling debug entry value production by default > > Yep, TAG_call_site_parameter and its children shouldn't require any extra relocations. Thanks! >...

> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), >> BlockFrequencyI...

...M To: Djordje Todorovic <Djordje.Todorovic at syrmia.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Cc: paul.robinson at sony.com <paul.robinson at sony.com>; asowda at cisco.com <asowda at cisco.com>; jeremy.morse at sony.com <jeremy.morse at sony.com>; ibaev at cisco.com <ibaev at cisco.com>; vsk at apple.com <vsk at apple.com>; aprantl at apple.com <aprantl at apple.com>; Petar Jovanovic <petar.jovanovic at syrmia.com>; Nikola Tesic <Nikola.Tesic at syrmia.com>; dblaikie at gmail.com <dblaikie at gmail.com> Subject:...

> Date: Tue, 14 Apr 2015 21:33:03 -0700 > From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] RFC: Metadata attachments to function definitions > Message-ID: <BF4002F0-06DC-4A25-AF84-7D21AD48121A at apple.com> > Content-Type: text/plain; charset=us-ascii > >

On 04/15/15 12:55, Duncan P. N. Exon Smith wrote: >> On 2015-Apr-15, at 08:11, Ivan Baev <ibaev at codeaurora.org> wrote: >> >>> Date: Tue, 14 Apr 2015 21:33:03 -0700 >>> From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> >>> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >>> Subject: [LLVMdev] RFC: Metadata...

Hi, we got the following assert: assert(!Working[0].isLoopHeader() && "entry block is a loop header"); [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), BlockFrequencyInfoImpl.h] on a Hexagon target - the entry block is a loop header. Has someone seen this assert on other targets? What would be a preferable way to fix it: - extend BlockFrequency pass to

Yep, TAG_call_site_parameter and its children shouldn't require any extra relocations. Thanks! vedant > On Feb 7, 2020, at 2:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > For that sort of small growth, if it doesn't add more relocations (I think the call sites need them (but they're already emitted/that's not what we're discussing enabling here), but

Hi all, The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with

Hi, we've implemented an indirect call promotion llvm pass. The design notes including examples are shown below. This pass complements the indirect call profile infrastructure http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084271.html Your feedback and comments will be highly appreciated. Thanks, Ivan ============================================================================RFC:

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

...review will be posted soon. RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters Ananthakrishna Sowda(Cisco), asowda at cisco.com Nikola Prica (RT-RK/Cisco), nprica at rtrk.com Djordje Todorovic(RT-RK/Cisco), djtodorovic at rtrk.com Ivan Baev (Cisco), ibaev at cisco.com Overview of the problem Software release products are compiled with optimization level –O2 and higher. Such products might produce a core-file in case of a failure. Support engineers usually begin debug analysis by looking at the backtrace from a core-file. Unfortunately, many param...

...Improving Debug Information in LLVM to Recover Optimized-out Function Parameters > > Ananthakrishna Sowda(Cisco), asowda at cisco.com > Nikola Prica (RT-RK/Cisco), nprica at rtrk.com > Djordje Todorovic(RT-RK/Cisco), djtodorovic at rtrk.com > Ivan Baev (Cisco), ibaev at cisco.com > > > Overview of the problem > Software release products are compiled with optimization level –O2 and higher. Such products might produce a core-file in case of a failure. Support engineers usually begin debug analysis by looking at the backtrace from a...

...> Optimized-out Function Parameters > > > > Ananthakrishna Sowda(Cisco), asowda at cisco.com > > Nikola Prica (RT-RK/Cisco), nprica at rtrk.com > > Djordje Todorovic(RT-RK/Cisco), djtodorovic at rtrk.com > > Ivan Baev (Cisco), ibaev at cisco.com > > > > > > Overview of the problem > > Software release products are compiled with optimization level –O2 > and higher. Such products might produce a core-file in case of a failure. > Support engineers usually begin...