This patch stems from D84112. This patch includes changes for SROA optimization.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
I see what seem to be changes to codegen here (see inline comments), is that intentional? And if so, why is that needed for DW_OP_LLVM_explicit_pointer to work?
llvm/lib/IR/Metadata.cpp | ||
---|---|---|
395 | Why is this now permitted behaviour? | |
llvm/lib/Transforms/Scalar/EarlyCSE.cpp | ||
1438–1443 | Is this necessary for the implicit pointer work? | |
llvm/lib/Transforms/Scalar/SROA.cpp | ||
4366 | Again, this block of code will need comments about its purpose adding. | |
4396–4400 | This part looks like it's changing the code generated, replacing a GEP with an alloca. If that's the case, IMO this should be split out into a different patch (one for codegen, one for debuginfo), as any codegen change will need an independent argument as to why it's a good idea. Plus, this would only be a codegen change for people building with dwarf-5, which would mean you get different code with and without the -g option to clang. | |
llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp | ||
424 | This should be folded into the previous patch (7?) |
This change was brought up in https://github.com/llvm/llvm-project/issues/54290, @alok is this still active? Is there a way we can help to get this patch stack reviewed and landed?
Looks like there was some further discussion here: https://reviews.llvm.org/D84112 and an alluded to llvm-dev thread that might be worth finding.
Also, I really wonder if it might be worth proposing a more flexible DWARF form/operator for this encoding. Currently the implicit_pointer only allows describing the pointer as pointing to another variable described by a variable DIE - I think it'd be nice to be able to avoid that indirection and creating synthetic variables to describe this in its full generality - and instead being able to describe the location (& maybe you need to point to a type too, but not a whole variable) directly in this variable location, maybe. It'd more closely model how I was leaning towards/pushing for this to be implemented in LLVM (LLVM_explicit_pointer was the prototype name) & I think makes more sense in general (in many cases you wouldn't be pointing to a known/named variable anyway - you could be pointing to a value in the calling frame that could be a composite itself, maybe several levels of indirection have been removed, etc)
I believe the corresponding discussion is https://discourse.llvm.org/t/dw-op-implicit-pointer-design-implementation-in-general/53698
It seems like not all the content was transferred over to Discourse, the original thread is https://lists.llvm.org/pipermail/llvm-dev/2019-November/136798.html
Why is this now permitted behaviour?