Page MenuHomePhabricator
Feed Advanced Search

Wed, Sep 16

alok added a comment to D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Thanks @aprantl for reviewing this. Any idea how to backport it to LLVM 11

Wed, Sep 16, 1:57 AM · Restricted Project, debug-info
alok committed rG159abe09d25b: [DebugInfo][flang] DISubrange support for fortran assumed size array (authored by alok).
[DebugInfo][flang] DISubrange support for fortran assumed size array
Wed, Sep 16, 1:46 AM
alok closed D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Wed, Sep 16, 1:46 AM · Restricted Project, debug-info

Sat, Sep 12

alok updated the diff for D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Incorporated comment from @aprantl .

Sat, Sep 12, 11:46 AM · Restricted Project, debug-info
alok added inline comments to D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Sat, Sep 12, 11:07 AM · Restricted Project, debug-info

Fri, Sep 11

alok updated the diff for D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Updated to incorporate comment from @aprantl .

Fri, Sep 11, 11:36 PM · Restricted Project, debug-info
alok added inline comments to D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Fri, Sep 11, 11:35 PM · Restricted Project, debug-info
alok updated the diff for D87500: [DebugInfo] DISubrange support for fortran assumed size array.

Updated to incorporate @aprantl 's comment.

Fri, Sep 11, 10:59 AM · Restricted Project, debug-info
alok added inline comments to D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Fri, Sep 11, 10:54 AM · Restricted Project, debug-info
alok requested review of D87500: [DebugInfo] DISubrange support for fortran assumed size array.
Fri, Sep 11, 2:33 AM · Restricted Project, debug-info
alok requested review of D87499: [DebugInfo] Flang should not emit DW_AT_main_subprogram for DWARF version lower than 4.
Fri, Sep 11, 2:28 AM · Restricted Project, debug-info

Thu, Sep 10

alok added a comment to D87406: [DebugInfo] Fixing CodeView assert related to lowerBound field of DISubrange..
In D87406#2266722, @rnk wrote:

I would ask you to add a test, but I can't recommend the existing test, llvm/test/DebugInfo/COFF/types-array.ll, as a good basis for a test. I'll look into rewriting it and adding coverage after you land.

Thu, Sep 10, 10:48 PM · Restricted Project, debug-info
alok updated the diff for D87406: [DebugInfo] Fixing CodeView assert related to lowerBound field of DISubrange..
Thu, Sep 10, 1:43 PM · Restricted Project, debug-info
alok added inline comments to D87406: [DebugInfo] Fixing CodeView assert related to lowerBound field of DISubrange..
Thu, Sep 10, 1:13 PM · Restricted Project, debug-info
alok added a reviewer for D87406: [DebugInfo] Fixing CodeView assert related to lowerBound field of DISubrange.: rnk.
Thu, Sep 10, 1:13 PM · Restricted Project, debug-info

Wed, Sep 9

alok requested review of D87406: [DebugInfo] Fixing CodeView assert related to lowerBound field of DISubrange..
Wed, Sep 9, 11:45 AM · Restricted Project, debug-info

Aug 12 2020

alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

@jmorse do you have any more comment on this ?

Aug 12 2020, 7:16 AM · Restricted Project, debug-info
alok added a comment to D84113: [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.

@jmorse Do you have any more comment on this ?

Aug 12 2020, 7:15 AM · Restricted Project, debug-info

Aug 3 2020

alok retitled D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer. from [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_explicit_pointer. to [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..
Aug 3 2020, 8:14 AM · Restricted Project, debug-info
alok added a comment to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

Similar story to the parent patch, could you put a file-comment into the test explaining it's a round-trip test?

Aug 3 2020, 7:59 AM · Restricted Project, debug-info
alok updated the diff for D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..

Incorporated comments from @jmorse .

Aug 3 2020, 7:58 AM · Restricted Project, debug-info
alok updated the diff for D84113: [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.
Aug 3 2020, 7:38 AM · Restricted Project, debug-info
alok added a reviewer for D84113: [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer: jmorse.
Aug 3 2020, 4:06 AM · Restricted Project, debug-info
alok added a comment to D84113: [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer.

Thanks for your reviewing this.

Aug 3 2020, 4:05 AM · Restricted Project, debug-info

Jul 20 2020

alok updated the summary of D84112: [DebugInfo] Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy)..
Jul 20 2020, 10:43 PM · debug-info, Restricted Project

Jul 18 2020

Herald added a project to D84120: [Debuginfo] (8/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:14 PM · debug-info, Restricted Project
Herald added a project to D84119: [Debuginfo] (7/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:11 PM · Restricted Project, debug-info
Herald added a project to D84118: [Debuginfo] (6/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:09 PM · Restricted Project, debug-info
Herald added a project to D84117: [Debuginfo] (5/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:06 PM · debug-info, Restricted Project
Herald added a project to D84116: [Debuginfo] (4/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:04 PM · Restricted Project, debug-info
Herald added a project to D84115: [Debuginfo] (3/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 5:02 PM · Restricted Project, debug-info
Herald added a project to D84114: [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer.: Restricted Project.
Jul 18 2020, 4:58 PM · Restricted Project, debug-info
Herald added a project to D84113: [Debuginfo] (1/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_implicit_pointer: Restricted Project.
Jul 18 2020, 4:54 PM · Restricted Project, debug-info
Herald added a project to D84112: [DebugInfo] Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy).: Restricted Project.
Jul 18 2020, 4:21 PM · debug-info, Restricted Project

Jul 15 2020

alok updated the diff for D83544: [DebugInfo] Support for DW_AT_associated and DW_AT_allocated..

Incorporated comments from @aprantl .

Jul 15 2020, 11:16 AM · debug-info, Restricted Project
alok added a comment to D83544: [DebugInfo] Support for DW_AT_associated and DW_AT_allocated..

Mechanically, this looks great! it would be good to add a little more context to the LangRef documentation (see my inline comment).

Jul 15 2020, 9:45 AM · debug-info, Restricted Project

Jul 10 2020

Herald added a project to D83544: [DebugInfo] Support for DW_AT_associated and DW_AT_allocated.: Restricted Project.
Jul 10 2020, 4:17 AM · debug-info, Restricted Project

May 28 2020

alok added inline comments to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.
May 28 2020, 7:02 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

This breaks check-llvm on Windows: http://45.33.8.238/win/16214/step_11.txt

Please take a look and revert if it takes a while to investigate.

May 28 2020, 5:57 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Thanks! I think it would be good to update clang to explicitly pass a nullptr, then we won't have as much churn in the IR for existing testcases. I think this is ready to land with that patch applied.

May 28 2020, 1:35 AM · Restricted Project, Restricted Project, debug-info
alok added inline comments to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.
May 28 2020, 1:35 AM · Restricted Project, Restricted Project, debug-info

May 27 2020

alok updated the diff for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Incorporated comments from @aprantl and re-based.

May 27 2020, 10:50 AM · Restricted Project, Restricted Project, debug-info
alok added a comment to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Can you confirm that this patch doesn't cause us to emit a DW_AT_lower_bound(0) where we previously didn't?

May 27 2020, 10:17 AM · Restricted Project, Restricted Project, debug-info

May 23 2020

alok updated the diff for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Updated the patch for comments from @aprantl .

May 23 2020, 1:15 PM · Restricted Project, Restricted Project, debug-info
alok added a comment to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

I think this is pretty good. A couple of minor comments inline.

May 23 2020, 1:15 PM · Restricted Project, Restricted Project, debug-info

May 22 2020

alok updated the diff for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Re-based and incorporated comments from @jmorse .

May 22 2020, 1:24 PM · Restricted Project, Restricted Project, debug-info
alok added a comment to D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

I'm not incredibly familiar with bitcode and metadata, or Fortran at all, but left some comments which hopefully help. This in general looks pretty good -- do you think it's worth making Count and UpperBound mutually exclusive? Otherwise there's the chance to represent the same information twice (and thus inconsistently).

May 22 2020, 11:15 AM · Restricted Project, Restricted Project, debug-info

May 19 2020

alok updated the diff for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

Removed -mtriple from tests.

May 19 2020, 5:22 AM · Restricted Project, Restricted Project, debug-info
alok updated the summary of D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.
May 19 2020, 5:22 AM · Restricted Project, Restricted Project, debug-info
alok updated the diff for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.

This commit fixed clang testcases to change expected output for DISubstring which should include lowerBound=0, which is what is passed to constructor.
Below file is truncated in patch. while the test passes in my workarea. I am not sure how to include a binary file in patch.
llvm/test/Bitcode/fortranSubrangeBackward.ll.bc

May 19 2020, 5:22 AM · Restricted Project, Restricted Project, debug-info
alok added reviewers for D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays: aprantl, probinson, dblaikie, jmorse, vsk, dstenb, jini.susan.george, SouraVX.
May 19 2020, 2:40 AM · Restricted Project, Restricted Project, debug-info
alok created D80197: [DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays.
May 19 2020, 2:08 AM · Restricted Project, Restricted Project, debug-info

May 15 2020

alok added inline comments to D79592: [DebugInfo] support for DW_AT_data_location in llvm.
May 15 2020, 12:08 AM · Restricted Project, debug-info

May 13 2020

alok updated the diff for D79592: [DebugInfo] support for DW_AT_data_location in llvm.

Re-based and addressed comments from @aprantl

May 13 2020, 1:05 PM · Restricted Project, debug-info
alok added inline comments to D79592: [DebugInfo] support for DW_AT_data_location in llvm.
May 13 2020, 10:52 AM · Restricted Project, debug-info
alok updated the diff for D79306: llvm rejects DWARF operator DW_OP_push_object_address..

Addressed comments from @aprantl and re-based.

May 13 2020, 10:50 AM · Restricted Project, debug-info
alok added a comment to D79306: llvm rejects DWARF operator DW_OP_push_object_address..

From Paul's comment, it sounds like we do want to allow DW_OP_push_object_address in LLVM IR. Can you please add documentation for it to LangRef.rst or SourceLevelDebugging.rst (wherever the other operations are explained)?

May 13 2020, 10:50 AM · Restricted Project, debug-info

May 11 2020

alok added a comment to D79306: llvm rejects DWARF operator DW_OP_push_object_address..

Thanks a lot for the example!

If DW_OP_push_object address is *only* going to be used inside a DISubrange and if it *always* appears at the beginning of a DIExpression bound there, we could make it implicit, the same way the first operator of a "normal" DIExpression in a dbg.value is implicitly specified by the dbg.value.

My motivation behind this is to keep the surface area of DIExpression small. We don't necessarily want to include all DWARF operators in DIExpression, because it would make it harder to emit other debug info formats from it, transform the expression during optimizations, and generally reason about them.

Would changing the backend to emit an automatic DW_OP_push_object before each DIExpression that represents a bound in a DISubrange work for flang, or are there other kinds of bound expressions / reasons why that would be a bad idea?

I understand the concerns for keeping DIExpression small. But considering the DW_OP_push_object_address implicit would prevent the freedom to use expression which don't use this (DW_OP_push_object_address) DWARF operator. If it is big a 'no' for adding DW_OP_push_object_address to DIExpression, then as you suggested I would need DW_OP_LLVM_arg0 from https://reviews.llvm.org/D70642 .

My goal is to find the most consistent and useful design for LLVM IR.

Currently (without D70642) DIExpressions modify a location specified by the context in which they appear. A DIExpression bound to a dbg.value() might modify a DW_OP_reg, a DIExpression bound by a DIGlobalVariableExpression a DW_OP_addr, etc. Based on that prior art, it would seem logical to say that a DIExpressions inside a DISubrange implicitly starts with a DW_OP_push_object_address.

Thanks for the explanation and pointers.

May 11 2020, 2:01 PM · Restricted Project, debug-info
alok updated the diff for D79592: [DebugInfo] support for DW_AT_data_location in llvm.

Incorporated comments form @aprantl. In addition to that also updated dependencies function in file DwarfCompileUnit.cpp.

May 11 2020, 1:28 PM · Restricted Project, debug-info
alok added a comment to D79592: [DebugInfo] support for DW_AT_data_location in llvm.

Why is the data location a part of the type and not something dynamically bound via dbg.value or something similar?

What's an example for what a typical data location expression?

Dynamic arrays are represented by two things

  • allocated space
  • descriptor which describes the array bounds (always) and allocated space (not always)

DW_AT_location attached to DW_TAG_variable denotes descriptor, which is used by bounds (using DW_OP_push_object_address). Since DW_AT_location denotes descriptor, DW_AT_data_location is used to denote allocated space. DWARF has attached that to DW_TAG_array_type.
In cases when descriptor also has a pointer to allocated space (as in case of gfortran), DW_AT_data_location can also be described by DW_OP_push_object_address and offset where the pointer to allocated space is. In cases when descriptor does not have the pointer to allocated space (as in case of flang), DW_AT_data_location can be represented by DIE reference which denotes an artificial variable which has the data pointer (dbg.declare in IR).
Please let me know if you need more information.

Thanks. I read through the DWARF v5 spec and given that arrays are represented as DICompositeTypes this makes sense to me. Personally I find the DWARF nomenclature weird (it would make more sense if we had a DW_AT_type_descriptor and a DW_AT_location), but it's probably better to stick with the DWARF naming scheme here, or else this raises even more confusion.

Thanks for your attention and comments.

Can you please add a check to Verifier.cpp that checks that only arrays get a data location?

I shall update the patch with this.

Can you please add a round-trip test to test/Assembler/ (see dicompositetype-members.ll for an example)?

I have added the round trip test named llvm/test/Bitcode/dataLocation.ll, should I move this to Assembler directory?

Can you please extend the metadata unit test llvm/unittests/IR/MetadataTest.cpp to exercise the changes in LLVMContextImpl.h?

I shall update the patch to incorporate this.

Should this be added to DIBuilder?

As of now, flang front-end doesnt utilize these routines, we can defer it or update it now itself provided f18 is now part of LLVM and later we may need.

Can you add some form of documentation that explains what the new field is used for? Perhaps in the doxygen of DIBuilder, and/or in SourceLevelDebugging.rst or LangRef.rst?

May 11 2020, 1:28 PM · Restricted Project, debug-info

May 7 2020

alok added a comment to D79592: [DebugInfo] support for DW_AT_data_location in llvm.

Why is the data location a part of the type and not something dynamically bound via dbg.value or something similar?

What's an example for what a typical data location expression?

May 7 2020, 11:57 PM · Restricted Project, debug-info
alok updated the diff for D79592: [DebugInfo] support for DW_AT_data_location in llvm.

Incorporated comments from @vsk

May 7 2020, 11:16 PM · Restricted Project, debug-info
alok added inline comments to D79592: [DebugInfo] support for DW_AT_data_location in llvm.
May 7 2020, 11:16 PM · Restricted Project, debug-info
alok edited reviewers for D79592: [DebugInfo] support for DW_AT_data_location in llvm, added: aprantl, probinson, dblaikie, jmorse, vsk, dstenb, jini.susan.george, SouraVX; removed: sscalpone.
May 7 2020, 11:20 AM · Restricted Project, debug-info
alok created D79592: [DebugInfo] support for DW_AT_data_location in llvm.
May 7 2020, 11:20 AM · Restricted Project, debug-info

May 6 2020

alok added a comment to D79306: llvm rejects DWARF operator DW_OP_push_object_address..

Thanks a lot for the example!

If DW_OP_push_object address is *only* going to be used inside a DISubrange and if it *always* appears at the beginning of a DIExpression bound there, we could make it implicit, the same way the first operator of a "normal" DIExpression in a dbg.value is implicitly specified by the dbg.value.

My motivation behind this is to keep the surface area of DIExpression small. We don't necessarily want to include all DWARF operators in DIExpression, because it would make it harder to emit other debug info formats from it, transform the expression during optimizations, and generally reason about them.

Would changing the backend to emit an automatic DW_OP_push_object before each DIExpression that represents a bound in a DISubrange work for flang, or are there other kinds of bound expressions / reasons why that would be a bad idea?

May 6 2020, 12:25 PM · Restricted Project, debug-info

May 5 2020

alok updated the diff for D79306: llvm rejects DWARF operator DW_OP_push_object_address..

Updated for comments from @djtodoro .

May 5 2020, 3:11 AM · Restricted Project, debug-info
alok added inline comments to D79306: llvm rejects DWARF operator DW_OP_push_object_address..
May 5 2020, 3:11 AM · Restricted Project, debug-info
alok updated the diff for D79306: llvm rejects DWARF operator DW_OP_push_object_address..

update for comments from djtodoro

May 5 2020, 2:06 AM · Restricted Project, debug-info
alok added inline comments to D79306: llvm rejects DWARF operator DW_OP_push_object_address..
May 5 2020, 2:06 AM · Restricted Project, debug-info
alok added inline comments to D79306: llvm rejects DWARF operator DW_OP_push_object_address..
May 5 2020, 1:34 AM · Restricted Project, debug-info
alok added a comment to D79306: llvm rejects DWARF operator DW_OP_push_object_address..

Can you explain in more detail how flang is going to use this? In LLVM DIExpressions expressions we currently never refer to the SSA values that are bound to the expression via a dbg.value/dbg.declare from within the expression. We've had discussions about how to do this in the past (see https://reviews.llvm.org/D70642 and the discussions preceding it) and I would like to make sure that this fits well into the design.

It would be particularly helpful if you could post example LLVM IR that would be produced by flang to make use of this feature and the DWARF that should be generated from it.

May 5 2020, 1:34 AM · Restricted Project, debug-info

May 4 2020

alok added a comment to D79306: llvm rejects DWARF operator DW_OP_push_object_address..

I don't see you are touching the DIExpression::ExprOperand::getSize().

Can we verify the operation within DWARFVerifier ?

May 4 2020, 2:05 AM · Restricted Project, debug-info

May 3 2020

alok created D79306: llvm rejects DWARF operator DW_OP_push_object_address..
May 3 2020, 11:09 AM · Restricted Project, debug-info

May 2 2020

alok added a comment to D79190: llvm rejects DWARF operator DW_OP_lit[1-31] in IR.

when this stuff was added, do you recall if there was any particular goal around that? Was lit0 added for some specific reason/separate from adding litN? Or was it just an oversight? And/or do you have thoughts on which way this should go today?

As I said yesterday, I think it would be better to aim for a canonical representation in LLVM to make transformations easier. A quick grep for DW_OP_lit0 in llvm/lit shows no current use of this, so we could remove it in favor of DW_OP_constu 0.
Doing some archeology, lit0 was added by @vsk in https://reviews.llvm.org/D48676 but that code must have been removed since. We could easily write a bitcode upgrade to canonicalize existing occurrences of lit0.

May 2 2020, 7:23 AM · Restricted Project, debug-info

May 1 2020

alok updated the diff for D79190: llvm rejects DWARF operator DW_OP_lit[1-31] in IR.

Updated to address comments from @probinson

May 1 2020, 2:10 AM · Restricted Project, debug-info
alok added a comment to D79190: llvm rejects DWARF operator DW_OP_lit[1-31] in IR.

If I take your C input program and compile it to a .o file, I see that we do emit (DW_OP_lit13; DW_OP_lit0; DW_OP_mul; DW_OP_stack_value) for "var2".

I think what you are saying is, we do not accept DW_OP_litN as *input* in the IR. Is that correct? If so, please make sure the commit log states that.

May 1 2020, 1:48 AM · Restricted Project, debug-info

Apr 30 2020

alok created D79190: llvm rejects DWARF operator DW_OP_lit[1-31] in IR.
Apr 30 2020, 11:47 AM · Restricted Project, debug-info

Mar 1 2020

alok updated the diff for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

Updated for the comments from @vsk . Deleted definition and usage of function LdStHasDebugValue.

Mar 1 2020, 10:18 PM · Restricted Project, debug-info
alok added a comment to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
In D74030#1892727, @vsk wrote:
In D74030#1889750, @vsk wrote:

Now,

  1. Avoid insertion of duplicate dbg.value if immediate next instruction is identical dbg.value. (avoids generating duplicates for same load/store, forward scan is not done)

Why is it necessary to do (1)? If the goal is to have cleaner IR after LowerDbgDeclare, it seems like (2) achieves that.

Yes for me also it seems a bit difficult decision. There were few reasons which made me think to keep 1)
a) It looks clearer to avoid generating than first let it generate and later delete when there is no performance penalty. In case of avoiding generation of dbg.value for same load/store again and again there is a pattern (immediate previous/next instruction in question).

I'm not sure I understand how the IR could look clearer. It shouldn't make any difference if the redundant instructions are eliminated after all insertions occur. Unless there's some kind of significant compile time reduction to be had by keeping LdStHasDebugValue, I think we should get rid of it, as it'd just be adding unnecessary complexity.

b) There is existing functionality for avoiding generation in function named "LdStHasDebugValue", though the name suggests covering both load and store both but it had handling only for store, adding the case for load justifies its name and completes the functionality. Either we should remove this function completely or complete it.

Agreed! Strong +1 to this, it's just that I suspect deleting LdStHasDebugValue is the simpler way to go.

Mar 1 2020, 10:09 PM · Restricted Project, debug-info

Feb 25 2020

alok added a comment to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
In D74030#1889750, @vsk wrote:

Now,

  1. Avoid insertion of duplicate dbg.value if immediate next instruction is identical dbg.value. (avoids generating duplicates for same load/store, forward scan is not done)

Why is it necessary to do (1)? If the goal is to have cleaner IR after LowerDbgDeclare, it seems like (2) achieves that.

Feb 25 2020, 7:24 AM · Restricted Project, debug-info

Feb 23 2020

alok updated the diff for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

This is updated to re-base and addressing common concern about performance and suggestion form @vsk to use RemoveRedundantDbgInstrs.

Feb 23 2020, 11:21 PM · Restricted Project, debug-info
alok added a comment to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
In D74030#1888527, @vsk wrote:

@alok I had a quick stab at this to see what it would take, and the result turned out to be relatively clean: https://github.com/vedantk/llvm-project/commit/85d7fe06810fa7f6166508be73eef80f676b0fc6.diff. This handles the situation in your 'duplicate_dbgvalue.ll' test case. Lmk what you think. Feel free to commandeer the patch if you'd like, or if you don't have the bandwidth for that I can kick off a fresh review. Thanks!

Feb 23 2020, 9:21 PM · Restricted Project, debug-info

Feb 11 2020

alok updated the diff for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

Updated to incorporate review comments from Adrian (@aprantl) .

Feb 11 2020, 9:51 PM · Restricted Project, debug-info
alok added a comment to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

Thanks! No further comments from me.

I'll leave a chance for others that are more familiar with this code to have their say though.

Feb 11 2020, 8:22 PM · Restricted Project, debug-info
alok updated the diff for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

This version is updated to incorporate comments from David (@dstenb ).

Feb 11 2020, 2:33 AM · Restricted Project, debug-info
alok added inline comments to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
Feb 11 2020, 2:10 AM · Restricted Project, debug-info

Feb 10 2020

alok added a comment to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

Hi David (@dstenb), I have incorporated all your comments. I have also added you as reviewer. Kindly give your feedback.

Feb 10 2020, 10:00 PM · Restricted Project, debug-info

Feb 6 2020

alok updated the diff for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.

Updated to incorporate comments from @dstenb

Feb 6 2020, 9:49 PM · Restricted Project, debug-info
alok added inline comments to D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
Feb 6 2020, 8:46 PM · Restricted Project, debug-info
alok added a reviewer for D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value: dstenb.
Feb 6 2020, 8:42 PM · Restricted Project, debug-info

Feb 5 2020

alok created D74030: [DebugInfo] Avoid generating duplicate llvm.dbg.value.
Feb 5 2020, 2:12 AM · Restricted Project, debug-info

Jan 9 2020

alok updated the diff for D72055: [DebugInfo] Support for DW_OP_implicit_pointer (for temp references & dynamic allocations).

Re-based and cleanup.

Jan 9 2020, 8:30 PM · debug-info, Restricted Project
alok updated the diff for D70642: [DebugInfo] Support for DW_OP_implicit_pointer (DW_OP_LLVM_argN).

Re-based and some cleanup.

Jan 9 2020, 8:30 PM · debug-info, Restricted Project

Jan 6 2020

alok updated the diff for D70643: [DebugInfo] Support for DW_OP_implicit_pointer (DW_OP_LLVM_implicit_pointer).

Updated to re-base and include a test case as suggested by @aprantl.

Jan 6 2020, 8:51 PM · debug-info, Restricted Project
alok added a comment to D70643: [DebugInfo] Support for DW_OP_implicit_pointer (DW_OP_LLVM_implicit_pointer).

Can you please add an assembler round-trip test to test/IR that runs llvm-as | llvm-dis | llvm-as - | llvm-dis ? There are a bunch of examples in that directory.

Jan 6 2020, 8:43 PM · debug-info, Restricted Project

Jan 3 2020

alok updated the diff for D70642: [DebugInfo] Support for DW_OP_implicit_pointer (DW_OP_LLVM_argN).

This is re-based and updated to apply LLVM_arg0 to existing DWARF operator and to upgrade for older styled DWARF expressions. This is done as suggested by @aprantl .

Jan 3 2020, 3:37 AM · debug-info, Restricted Project

Jan 2 2020

alok updated the diff for D72055: [DebugInfo] Support for DW_OP_implicit_pointer (for temp references & dynamic allocations).

Re-based and updated.

Jan 2 2020, 12:03 PM · debug-info, Restricted Project
alok updated the diff for D70644: [DebugInfo] Support for DW_OP_implicit_pointer (llvm.dbg_derefval).

Rebased and updated.

Jan 2 2020, 12:03 PM · Restricted Project, debug-info, Restricted Project

Jan 1 2020

alok created D72055: [DebugInfo] Support for DW_OP_implicit_pointer (for temp references & dynamic allocations).
Jan 1 2020, 10:24 AM · debug-info, Restricted Project