Displaying 20 results from an estimated 500 matches similar to: "[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR"
2020 Sep 01
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
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
2020 Sep 09
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
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
2020 Sep 08
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
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
2019 Sep 11
3
Dwarf - 5 features in clang and llvm
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++
2019 Sep 10
2
Dwarf - 5 features in clang and llvm
> 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
2020 Jun 18
2
[DebugInfo] RFC: Introduce LLVM DI Checker utility
Hi Vedant,
Thanks a lot for your comments!
>It looks like a lot of the new infrastructure introduced here
<https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27> consists
of logic copied from the debugify implementation. Why is introducing a
new pair of passes better than extending the ones we have? The core
infrastructure needed to track
2019 Feb 08
3
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
2020 Jun 17
4
[DebugInfo] RFC: Introduce LLVM DI Checker utility
Hi,
I am sharing the proposal [0] which gives a brief introduction for the
implementation of the LLVM DI Checker utility. On a very high level, it
is a pair of LLVM (IR) Passes that check the preservation of the
original debug info in the optimizations. There are options controlling
the passes, that could be invoked from ``clang`` as well as from ``opt``
level.
By testing the utility on the
2019 Sep 10
2
Dwarf - 5 features in clang and llvm
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.
--------------
2019 Feb 07
2
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
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
2020 Feb 20
2
[LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.
> Could you please describe what is the benefit of that?
Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag
2020 Nov 11
1
[RFC] A value-tracking LiveDebugValues implementation
Hi Xiang,
On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote:
> Jeremy wrote:
> > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ...
>
> Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point,
>
2020 Feb 20
3
[LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.
Yes, removing the support for isLocal, isDefinition fields completely from ll files, currently the LLParser still parses it. I want to remove it and update the all the ll files which still uses it.
Also the metadata read will support old format, no changes in that.
so if ll file has isLocal and isDefinition it will result in parser error. But the bitcode read will work as usual.
- Chirag.
2019 Feb 08
2
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
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
2019 Dec 23
2
[INFO] Buildbot llvm-docs failure
Hi all,
It looks like the llvm-sphinx-docs fails for a long time (at least 20 days).
Can someone please confirm if this is true?
Best regards,
Djordje
2020 Feb 10
2
Enabling debug entry value production by default
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,
2020 Aug 25
3
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely
2020 Feb 20
3
[LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.
Hello,
In regard to the review request https://reviews.llvm.org/D74470,
I am trying to move five of the DIFlags to DISPFlag for the moment namely DIFlagExplicit, DIFlagPrototyped, DIFlagNoReturn, DIFlagThunk, DIFlagAllCallsDescribed.
The llvm ir format for DISubprogram currently has backword compatibility where the isLocal, isDefinition, virtuality, isOptimized and SPFlags are mutually exclusive.
2019 Feb 12
2
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
[+ 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.
2019 Feb 14
2
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
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