llvm dev - Jan 2016 - Should DISubprogram's scope be allowed to be null?

I'm looking at cases of disagreement between assertions in the backend and
what the Verifier checks for (for http://reviews.llvm.org/D16083). One of
these seems to be the question of whether a DISuprogram may exist without a
DICompileUnit. Currently the Verifier doesn't care, but there are a few
assertions to this extent in the backend.
Possible options are:

1) A DISubprogram may exist without a DICompileUnit (what would we have to
change in the backend?)
2) A DISubprogram's scope may be null, but only if there's a
DICompileUnit
that references it.
3) A DISubprogram's scope may not be null, but the referenced DICompileUnit
need not necessarily contain it
4) A DISubprogram's scope may not be null, and the referenced DICompileUnit
must contain it

As far as I can tell, all of these would need some amount of changes to
either existing code or existing test cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160115/c970daab/attachment.html>

Looking at this again, I think I was under the mistaken impression that the
DISubprogram's scope would have to be the compile unit, but it seems we
also currently allow it to be a DIFile (or any other kind of scope). In
that case, I suppose the behavior that the backend expects is that every
DISubprogram is referenced from some DICompileUnit contained in llvm.dbg.cu.
I'll implement a Verifier pass to that extent.

On Fri, Jan 15, 2016 at 4:26 AM, Keno Fischer <kfischer at
college.harvard.edu>
wrote:
> I'm looking at cases of disagreement between assertions in the backend
and
> what the Verifier checks for (for http://reviews.llvm.org/D16083). One of
> these seems to be the question of whether a DISuprogram may exist without a
> DICompileUnit. Currently the Verifier doesn't care, but there are a few
> assertions to this extent in the backend.
> Possible options are:
>
> 1) A DISubprogram may exist without a DICompileUnit (what would we have to
> change in the backend?)
> 2) A DISubprogram's scope may be null, but only if there's a
DICompileUnit
> that references it.
> 3) A DISubprogram's scope may not be null, but the referenced
> DICompileUnit need not necessarily contain it
> 4) A DISubprogram's scope may not be null, and the referenced
> DICompileUnit must contain it
>
> As far as I can tell, all of these would need some amount of changes to
> either existing code or existing test cases.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160115/3ce28fa4/attachment.html>

> On 2016-Jan-15, at 06:46, Keno Fischer <kfischer at
college.harvard.edu> wrote:
> 
> Looking at this again, I think I was under the mistaken impression that the
DISubprogram's scope would have to be the compile unit, but it seems we also
currently allow it to be a DIFile (or any other kind of scope). In that case, I
suppose the behavior that the backend expects is that every DISubprogram is
referenced from some DICompileUnit contained in llvm.dbg.cu. I'll implement
a Verifier pass to that extent.
Two things I remember:
1. There's difference between subprogram definitions and subprogram
declarations.  Declarations seem to just be part of the type hierarchy.
2. Subprogram definitions need to be referenced from the compile units.

IMO this link (2) should be reversed:  we should reference compile units from
subprogram definitions (through a new cu: field) and drop the reference in the
other direction.  This would be far more convenient for LTO (or llvm-link in
general), but it causes a semantic change and I never worked through the
implications of that.
> On Fri, Jan 15, 2016 at 4:26 AM, Keno Fischer <kfischer at
college.harvard.edu> wrote:
> I'm looking at cases of disagreement between assertions in the backend
and what the Verifier checks for (for http://reviews.llvm.org/D16083). One of
these seems to be the question of whether a DISuprogram may exist without a
DICompileUnit. Currently the Verifier doesn't care, but there are a few
assertions to this extent in the backend.
> Possible options are:
> 
> 1) A DISubprogram may exist without a DICompileUnit (what would we have to
change in the backend?)
> 2) A DISubprogram's scope may be null, but only if there's a
DICompileUnit that references it.
> 3) A DISubprogram's scope may not be null, but the referenced
DICompileUnit need not necessarily contain it
> 4) A DISubprogram's scope may not be null, and the referenced
DICompileUnit must contain it
> 
> As far as I can tell, all of these would need some amount of changes to
either existing code or existing test cases.
>