similar to: RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters

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

On 2/8/19, 7:15 AM, "paul.robinson at sony.com" <paul.robinson at sony.com> wrote: It's fantastic to see this happening! It'll be really nice to start seeing some DWARF 5 feature work (as opposed to the infrastructure stuff, which has its own benefits but doesn't help the end-user's debugging experience). A couple of questions below. --paulr

[+ some folks more knowledgable about the Machine layer than me.] > On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > Hi, > > I am one of the authors of this feature. On Phabricator, we agreed to > take discussion whether encoding this in IR and threading it through the > compiler or performing a late MIR analysis is the better approach.

Hi, [+ Quentin] Sorry for the late reply. > On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > On 12.02.2019. 18:06, Adrian Prantl wrote: >> [+ some folks more knowledgable about the Machine layer than me.] >> > That would be useful for us too! :) > > >>> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at

Hi all, As much as possible I would rather we avoid any kind of metadata in MIR to express the semantic of instructions. Instead I would prefer that each back provides a way to interpret what an instruction is doing. What I have in mind is something that would generalize what we do in the peephole optimizer for instance (look for isRegSequenceLike/getRegSequenceInputs and co.) or what we have for

Hi, We have done some investigation. Please find my comment inlined bellow. > > On 14.02.2019. 20:20, Quentin Colombet wrote: >> Hi all, >> >> As much as possible I would rather we avoid any kind of metadata in MIR >> to express the semantic of instructions. >> Instead I would prefer that each back provides a way to interpret what >> an instruction is

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 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

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

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 llvm-dev@ LNT produces statistics and graphs (such as [0]) of debuginfo metrics, such as number of source variables with locations. It looks like these haven't run [1] since the move from svn to git -- are there any plans to get these running again? I find it highly useful to identify what commits have affected variable locations and how significant an affect. [0]

Hello All, I was working on some dwarf-5 features and debugging optimized code support in clang and llvm. Noticed that, DW_TAG_call_site is supported in llvm middle-end. but clang is not emitting these. I was hoping, if someone could provide current status of these features and current status of dwarf-5 features in clang and llvm. That will be immensely helpful. Thanks! Sourabh. --------------

> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end. > Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to > the DW_AT_call_all_calls. > > There is also

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++

Hi debug-info folks, Time for another update on the variable location "instruction referencing" implementation I've been doing, see this RFC [0, 1] for background. It's now at the point where I'd call it "done" (as far as software ever is), and so it's a good time to look at what results it produces. And here are the scores-on-the-doors using llvm-locstats, on

In the past 2 months another change occurred in the CVS code that broke my ssh-keyscan patch. Here's an updated version that tweaks the changed name (in the Kex struct) and also causes an attempt to grab an ssh2 key from an older server (without ssh2 support) to fail earlier and without an error message (Stuart Pearlman emailed me some code for this). This patch is based on the BSD CVS

Hi, 1. I think you should apply the attached patch to openssh-2.9p1, otherwise ssh-keyscan on linux boxes with glibc-2.1 will experience enormous timeout delays. 2. Is there a program like ssh-keyscan for the Version2 (dsa and rsa) keys?? regards Peter Breitenlohner <peb at mppmu.mpg.de> -------------- next part -------------- diff -ur openssh-2.9p1.orig/ssh-keyscan.c

In IntrinsicEmitter::EmitTypeGenerate, called from IntrinsicEmitter::EmitGenerator, here for (unsigned j = 0; j != N; ++j) { OS << " ArgTys.push_back("; EmitTypeGenerate(OS, ParamTys[j], ArgNo); OS << ");\n"; } I'm hitting this assertion: if (ArgType->isSubClassOf("LLVMMatchType")) { unsigned Number =

That's a bug. I'm working on a fix.... On Apr 15, 2009, at 10:16 AM, Villmow, Micah wrote: > In IntrinsicEmitter::EmitTypeGenerate, called from > IntrinsicEmitter::EmitGenerator, here > for (unsigned j = 0; j != N; ++j) { > OS << " ArgTys.push_back("; > EmitTypeGenerate(OS, ParamTys[j], ArgNo); > OS << ");\n"; > }

Oops. That was premature. I think your original question was on the right track. TableGen distinguishes between known and "overloaded" types (like "llvm_anyfloat_ty" in your example). The overloaded types are numbered separately, and the argument to LLVMMatchType is an index into these overloaded types, ignoring the known types. So, in your case, the first