search for: dicallsiteparam

...ng > instructions from ISEL phase we are able to cover some of them without > such interpretor. I don’t have an opinion on this, but it sounds like this is going to grow into the full-MIR solution that Adrian was suggesting from the beginning. > > ISEL phase is important for matching DICallSiteParam metadata to > respective DBG_CALLSITEPARAM. It also recognizes COPY instructions that > are part of calling sequence but do not forward any argument (for > example for variadic, C calling convention, functions we have copy to AL > register). If we are able to dispatch such non transferr...

...nt. We generate call-site information when the call-site parameter values can be evaluated by unwinding to the parent frame. Only debugger can tell if look-up of an entry value finds matching call site and call site parameter. > For call-site information, new DINode metadata DICallSite and DICallSiteParam are defined and these are emitted by the Clang frontend. The metadata is associated to the call or invoke IR instruction. Here is an example: > > %call5 = call i32 @fed_em_strncmp(i8* %arraydecay, i8* %arraydecay1, i64 5), !dbg !114, !call_site !101 > … > !99 = !DICallS...

...when we lose track of parameter’s location. As a natural way of handling this problem we used Clang’s Sema and its constness check to embed this information in variable’s declaration which is later used for DILocalVariable construction. For call-site information, new DINode metadata DICallSite and DICallSiteParam are defined and these are emitted by the Clang frontend. The metadata is associated to the call or invoke IR instruction. Here is an example: %call5 = call i32 @fed_em_strncmp(i8* %arraydecay, i8* %arraydecay1, i64 5), !dbg !114, !call_site !101 … !99 = !DICallSiteParam(argno: 1, variable: !91, ex...

...ed. It's quite possible that the conclusion will be that the approach taken by the patch set is the right trade-off, but I want to make sure that we're rejecting the alternatives for the right technical reasons. > >> >>> >>> ISEL phase is important for matching DICallSiteParam metadata to >>> respective DBG_CALLSITEPARAM. > > Who is responsible for generating DICallSiteParam annotations? Is it the frontend or is it the codegenprepare(?) pass that knows about the calling convention? > >>> It also recognizes COPY instructions that >>>...

[+ 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.

...ideal match for an unmodified formal parameter. Yes, it is the idea. Even for lost values ( reported as optimized-out), showing @entry value has some benefit to the debug user. > > > > For call-site information, new DINode metadata DICallSite and > DICallSiteParam are defined and these are emitted by the Clang frontend. > The metadata is associated to the call or invoke IR instruction. Here is > an example: > > > > %call5 = call i32 @fed_em_strncmp(i8* %arraydecay, i8* %arraydecay1, > i64 5), !dbg !114, !call_...

...that the approach taken by >>> the patch set is the right trade-off, but I want to make sure that >>> we're rejecting the alternatives for the right technical reasons. >>> >>>> >>>>> >>>>> ISEL phase is important for matching DICallSiteParam metadata to >>>>> respective DBG_CALLSITEPARAM. >>> >>> Who is responsible for generating DICallSiteParam annotations? Is it >>> the frontend or is it the codegenprepare(?) pass that knows about the >>> calling convention? >>> > > I...