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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201005/d2693983/attachment.html>