<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 27, 2013, at 11:31 AM, John McCall wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Feb 27, 2013, at 10:12 AM, Manman Ren <<a href="mailto:mren@apple.com">mren@apple.com</a>> wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 26, 2013, at 9:36 AM, John McCall wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Feb 26, 2013, at 9:16 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Feb 25, 2013, at 5:02 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Feb 25, 2013, at 4:55 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">heres another patch for review:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Allocate stack storage for .block_descriptor and captured self.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This way the register allocator will not optimize away the the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">debug info for captured variables.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Allocating stack storage is not the right way to fix this problem.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The frontend is emitting the right intrinsics to say that the argument<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">is being kept in an LLVM value, not in memory. If that's not working,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">then basically all optimized debug info is useless.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Just to provide you with more details: The problem manifested itself even at -O0 because the DebugValue would be kicked out by RegAllocFast.cpp:855 under high register pressure (I think). Is there another, better way to force the DebugValue to survive register allocation?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is the value being lost completely (because it's no longer live), or is it just being moved between registers or spilled? Because it seems to me that it's a perfectly reasonable request to make of register allocation that it not drop debug info for live values.<br></blockquote></blockquote><blockquote type="cite">Here is what happened in the backend:<br></blockquote><blockquote type="cite">%vreg23<def> = COPY %vreg5;<br></blockquote><blockquote type="cite">%vreg22<def, tied 1> = ADD64ri32 %vreg23<tied0>
<br></blockquote><blockquote type="cite">DBG_VALUE %vreg23, 0, !"self"<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The last usage of %vreg23 is in DBG_VALUE. When processing ADD64ri32, since %vreg23 was only used in DBG_VALUE afterwards, its content was not spilled to stack.<br></blockquote><blockquote type="cite">At DBG_VALUE, %vreg23 is lost, it is not in a physical register, nor in a spill slot. And we will see error message "Unable to allocate vreg used by DBG_VALUE".<br></blockquote><br>Okay, you're saying that the value is actually no longer live at all at this point in the function? It seems reasonable to lose track of the debug info then, although we should be leaving behind a marker in the DWARF that says the value is unavailable.<br></div></blockquote><div><br></div>A little more details:</div><div><div>The related LLVM IR looks like:</div><div><div>define internal void @"__39-_block_invoke_2"(i8* %.block_descriptor, i8* %object, %7* %change2, i8* %stopObserving2) uwtable ssp {</div><div>entry:</div></div><div>...</div><div> call void @llvm.dbg.value(metadata !{i8* %.block_descriptor}, i64 0, metadata !<b>3846</b>), !dbg !3856</div><div>
</div><div><div> %block = bitcast i8* %.block_descriptor to <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, %2* }>*, !dbg !3856</div><div> %block.captured-self = getelementptr inbounds <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, %2* }>* %block, i32 0, i32 5, !dbg !3856</div><div> call void @llvm.dbg.declare(metadata !{<{ i8*, i32, i32, i8*, %struct.__block_descriptor*, %2* }>* %block}, metadata !<b>3860</b>), !dbg !3861</div></div><div>
</div><div>}</div><div><br></div><div>%block is associated with !3860, which is variable self, %block is not used after dbg.declare, but block.captured-self is used afterwards.</div><div>bitcast is converted to COPY, getelementptr is converted to ADD64ri32, and dgb.declare is converted to DBG_VALUE.</div><div><br></div><div>Yes, %block (%vreg23) is no longer live after dbg.declare(DGB_VALUE).</div><div><br></div><div>Thanks,</div><div>Manman</div><blockquote type="cite"><div><br>If we want to make stronger guarantees in -O0 for purposes of debugging and I think that's reasonable then throwing the value in an alloca is acceptable.<br><br>John.</div></blockquote></div><br></body></html>