[PATCH] D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass.

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

Adrian wrote:

> Stepping back a bit: Is the result of SROA multiple smaller allocas?
> 
> If SROA is only creating new allocas, then describing them with dbg.declares should do no harm, since a later call to LowerDbgDeclare would truncate their range by inserting new dbg.values at every load. But if SROA is inserting the load, we do need to make sure that the loaded value is tracked by a dbg.value (potentially in addition to tracking the alloca with a dbg.declare). So I guess my question is, where are loads for the SROAed allocas generated?

My understanding of SROA is that no new loads are generated, instead existing ones using GEPs and bitcasts are rewritten to use the smaller allocas. Any dbg.declare get fragmented into the smaller allocas in the usual way, then mem2reg / LowerDbgDeclare promotes in the usual way. In some circumstances the same load might get duplicated to enable promotion, such as:

  bb1:
    %a1 = alloca i32
    store i32 0, i32 *%a
    br label %join
  bb2:
    br label %join
  join:
    %b = phi i32 [ %a1, %bb1 ], [ @someglobal, %bb2 ]
    %c = load i32, i32 *%b

The load to %c gets duplicated into a load from %a1 in bb1, and from @someglobal in bb2, then the phi operates on the loaded values (and the alloca can be promoted). I don't think the loaded value qualifies as being part of the alloca after the phi, so IMO this wouldn't count as the location of a variable / field changing.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64595/new/

https://reviews.llvm.org/D64595