[llvm-dev] Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
Robinson, Paul via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 7 15:37:23 PDT 2017
If DBG_VALUE can distinguish then no problem. Thanks for your patience!
--paulr
From: Reid Kleckner [mailto:rnk at google.com]
Sent: Thursday, September 07, 2017 2:18 PM
To: Robinson, Paul
Cc: llvm-dev; David Blaikie; Adrian Prantl; Alex Bradbury; Chandler Carruth
Subject: Re: Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
Different intrinsics sounds like a good solution to me. ☺
So what happens with the case where a variable is registerized but later we decide to spill it? Presumably we'd have a dbg.addr to point to the spill slot. In past compilers I've used, spill slots were treated analogous to register allocation, i.e. some effort was made to minimize the number of spill slots and a variable might be spilled to different slots at different points. If LLVM does that, then dbg.addr will have to be allowed to associated different addresses with the variable. On the other hand, if LLVM allocates a unique memory "home" for each spilled variable, then dbg.addr can retain the property you suggest, that the address expression is always the same.
dbg.addr is really IR only. Machine DBG_VALUE instructions can already represent addresses or values depending on their second argument. At this point, I don't see any reason to change that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/690e55af/attachment.html>
More information about the llvm-dev
mailing list