[PATCH] D16228: [Verifier] Check that all subprogram definitions are reachable from dbg.cu

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 15 15:44:59 PST 2016


On Fri, Jan 15, 2016 at 3:25 PM, Keno Fischer via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> loladiro added a comment.
>
> The only cases I've found in the test cases that intentionally omit
> compile units from the .cu node are the AddDiscriminator tests. Are those
> the ones you are thinking about.


It's possibel that that's where it's showing up, but discriminators aren't
the things I was thinking of - we produce discriminators because we want
them in the debug info (not sure why these tests are omitting llvm.dbg.cu
at all).

There's some kind of backend diagnostic system - that's it "remarks" I
think they were called in the end. For the optimizers to report things like
"this failed to be inlined/vectorized/whatever". We use debug info to
identify the location for the diagnostics, if I remember correctly, but we
don't want just enabling remarks to turn on debug info emission, so we skip
putting the debug info in llvm.dbg.cu.


> For now, I made them all `isDefinition: false`.


That's a bit more hackish than the original hack - since these are clearly
subprogram definitions.


> However, if this is something we want to support (creating debug info, but
> not codegening it), how about we just create a different global named
> metadata `llvm.dbg.cu.noemit` (bad name, please suggest something better),
> into which we pull all compile units we don't want to emit, but the
> Verifier could still look at it.
>

Plausible - don't mind too much. Trying to rope Diego in so he can speak
more specifically about the functionality and how it's tested (or not, as
it would seem).

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160115/798aa7af/attachment.html>


More information about the llvm-commits mailing list