search for: tag_call_site_parameter

...o (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 I'll address it. However, there's an upside to maintaining all this CallSiteInfo even if TAG_call_site_parameters won't be emitted. The backend asserts whenever a MachineInstr carrying CallSiteInfo is destroyed without the call information being updated. This provides useful test coverage. vedant > On Feb 7, 2020, at 2:50 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > I’ve ask...

...o (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 I'll address it. However, there's an upside to maintaining all this CallSiteInfo even if TAG_call_site_parameters won't be emitted. The backend asserts whenever a MachineInstr carrying CallSiteInfo is destroyed without the call information being updated. This provides useful test coverage. > >   > > vedant > > > > On Feb 7, 2020, at 2:50 PM, Robinson, Paul <paul.robinso...

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

Hi all, I think we've reached a state where we're ready to enable debug entry value production by default for the x86_64, ARM, and AArch64 targets. For context, this is a debug info feature that allows debuggers to recover the value of unmodified optimized-out parameters by 'going up' a stack frame and interpreting spilled values, constants, etc. to work out what was passed to the