Jan 4 2021
Dec 18 2020
Updated the test filename to reflect the change made in D93559.
Thanks a lot, Aditya. Again, my apologies for the screw-up. I will make sure I won't make the same mistake next time I add a new file.
This diff breaks git source trees on case-insensitive filesystems, such as on macOS.
I did this on Linux, which is case-sensitive:$ find . |fgrep -i llvm/test/DebugInfo/X86/DIModule.ll ./llvm/test/DebugInfo/X86/DIModule.ll ./llvm/test/DebugInfo/X86/dimodule.ll
On a case-insensitive filesystem, these names collide and one overwrites the other, yeilding a tree with irreconcilable conflicts.
Please fix ASAP! Thanx!
Thanks for catching this for me. I don't work on Mac. :(
LGTM! Thanks for the patch.
One small thing, do you mind adding a one liner to release notes ? It would help in tracking extensions to Debug Metadata(previous extensions of DIModule were part of LLVM11).
Dec 17 2020
Dec 8 2020
Dec 7 2020
Dec 3 2020
Made changes based on the review comments.
Dec 1 2020
Oct 28 2020
Oct 26 2020
Typed the attributes as PointerUnion<DIExpression *, DIVariable *>, and updated the test to exercise the DIVariable case.
We can do that, but then the debugger would need to work a bit harder in order to get a constant, doesn't it? I don't feel strongly either way. If you do want it done the way you prefer, please let me know and I will make the change.
That's an interesting point. Do we emit different DWARF FORMs for constant vs constant DIExpression? An elegant solution would be to recognize constant DIExpressions in AsmPrinter (DIExpression::isConstant) and emit the same DWARF FORM we would emit for an IR constant if the expression is a constant.
Oct 23 2020
Reverted back to type those attributes as Metadata to allow DIVairbale.
Oct 22 2020
Also, DIBuilder::createConstantValueExpression(uint64_t) is already available for doing constant via DIExpression,, and its usage is demonstrated in the unit test.
Typed the attributes as DIExpression*, as suggested by @aprantl.
These can be DIExpression, ConstantAsMetadata, etc, so Metadata looks to be the right specificity (and the underlying 'get' function it calls types them as Metadata too).
Why do we need to accept both DIExpression and ConstantAsMetadata? Since we can also represent all constants as DIExpression, I think I would prefer to have only one way to represent a constant. Would it be feasible to expect clients to pass constants as DIExpression(DW_OP_constu, <number>, DW_OP_stack_value)? And if it doesn't already exist perhaps add a DIExpression *DIBuilder::createConstantExpression(unsigned value) API?
Oct 21 2020
Including the rank attribute in the patch.
Added a unit test for the patch.
Sorry. Please ignore Patch 2.
Per review comments, fixed/enhanced the description of createTypeArray.
Per review comments, fixed/enhanced the description of createArrayType.
Regarding test: Does the test idea laid out in my opening comment sound reasonable?
Oct 20 2020
I'd appreciate some guidance on what test to add for this change. Would it be sufficient to have a unittest that calls createArrayType to create a DICompositeType, and then get the three new attributes back from the DICompositeType using the getRaw* functions to check that they match with the arguments to the createArrayType call? Thanks.