similar to: [LLVMdev] RFC: Metadata attachments to function definitions

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:

> On 2015 Apr 14, at 21:46, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Apr 14, 2015 at 9:33 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >> `Function` definitions should support `MDNode` attachments, with a >> similar syntax to instructions: >> >> define void @foo() nounwind !attach !0 { >>

> On 2015 Apr 15, at 10:06, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Apr 14, 2015 at 10:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015 Apr 14, at 21:46, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Apr 14, 2015 at 9:33 PM, Duncan P. N. Exon Smith > > <dexonsmith at

> On 2015-Apr-15, at 08:59, Reid Kleckner <rnk at google.com> wrote: > > Conventional wisdom, which is often wrong, says that bytes in Function are precious. In the past we've bent over backwards to put bits on Function and have DenseMaps in LLVMContexts and Modules. I think this is probably the *wrong* approach for debug info, which, when it's being used, is used

> 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

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

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:

All, I'm needing volunteers to help moderate the sessions of the LLVM Developers' Meeting. All you need to do is introduce the speaker, make sure the speaker stays on time, and run Q&A at the end (run a microphone, select people, etc). Its a pretty easy job, but critical for our meeting to run smoothly. If you are interested in moderating, please send me your top 2 session choices.

David Is this true for static heuristics as well ? If the bb freqs are scaled wrt to the entry block freq and a) use such scaled freqs for the bb's that have calls b) propagate 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

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

Hi, Following is a proposal to improve location coverage for Function parameters in LLVM. The patches for 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

The actual DWARF emission for call site parameters is gated inside of DwarfDebug::constructCallSiteEntryDIEs by `tuneForGDB() || tuneForLLDB()`. However, we are creating+updating CallSiteInfo (basically, in-memory only bookkeeping used by the backend to keep track of call sites) even when the debugger tuning is set to the Sony debugger. If this creates problems, feel free to file a bug and

Hi, Thanks you all for the collaboration! :) Paul, > This is not how tuning-controlled features are supposed to work. I will comment on the review. I see, I am working on addressing the comments from the [1]. I will update the diff asap. Thanks. Vedant, There are no entry values generated at -O0 level, but I will add a test case for it. Thanks. Best regards, Djordje On 8.2.20. 02:41,

Thank you for your interest and comments! Please see my responses inline. On 2/7/19, 3:17 PM, "aprantl at apple.com on behalf of Adrian Prantl" <aprantl at apple.com> wrote: > On Feb 7, 2019, at 1:49 PM, Ananthakrishna Sowda (asowda) via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > Following is a proposal to improve location

Hi David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

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

On Tue, Aug 15, 2017 at 01:04:11PM +0000, Hatazaki, Takao wrote: > Ji-Hyeon, > > You're saying that "stripe=2 transport=rdma" should work. Ok, that > was firstly I wanted to know. I'll put together logs later this week. Note that "stripe" is not tested much and practically unmaintained. We do not advise you to use it. If you have large files that you

> On 2015-Apr-15, at 10:03, Reid Kleckner <rnk at google.com> wrote: > > On Wed, Apr 15, 2015 at 9:46 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I'm happy to defer to conventional wisdom here if anyone wants me to > (and TBH, I've only been looking at profiles that include debug info, > so maybe `sizeof(Function)` matters with -g0). >

On Wed, Oct 15, 2014 at 8:53 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > As all of these transforms are 1-to-1, can we still support the older metadata and convert it on the fly? > I'd prefer not to keep all of that code around to interpret both versions without a very good reason. -eric > Alex > >> On Oct 13, 2014, at 3:02 PM, Duncan P. N. Exon Smith

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