[llvm-dev] llvm.dbg.declare constraints

[Adrian Prantl via llvm-dev]

As I said in my last message, the backend can AFAIK only keep track of one declare per variable so it would be undefined which one survived.

-- adrian

> On Oct 5, 2020, at 9:13 AM, Xun Li <lxfind at gmail.com> wrote:
> 
> Thanks. Would there be any consequences if there are multiple
> dbg.declare for the same variable, and if they point to different
> aliases of the same address?
> 
> On Mon, Oct 5, 2020 at 9:01 AM Adrian Prantl <aprantl at apple.com> wrote:
>> 
>> The documentation is correct, and the observation that the IR verifier is currently not verifying this property is also correct. Due to the way that dbg.declares are handled by later stages, LLVM can only keep track of one dbg.declare per variable and that is intentional. The dbg.declare intrinsic is supposed to pin a variable to a stack slot, such as in the code that clang emits at -O0. If you need something different, use dbg.value. Adding a verifier check would be appreciated, but it may be a bit of work to get all of LLVM to adhere to it.
>> 
>> -- adrian
>> 
>> On Oct 4, 2020, at 10:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> 
>> +Aprantl for debug info IR metadata verifier things
>> 
>> I don't think the verifier's rigorously comprehensive - so probably somewhere between "intended/acceptable" and "a bug".
>> 
>> Not sure what the consequences might be.
>> 
>> On Sun, Oct 4, 2020 at 10:03 PM Xun Li via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Hi,
>>> 
>>> In the LLVM documentation it says "there can only be one call to
>>> llvm.dbg.declare for a given concrete local variable."
>>> However we don't seem to be checking it. opt tool can process IR that
>>> violates this rule without complaining. Is this intended, or is it a
>>> bug? What would be the consequence when this constraint is broken?
>>> 
>>> --
>>> Xun
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> 
> 
> 
> -- 
> Xun