[llvm-dev] Should DISubprogram's scope be allowed to be null?

[Duncan P. N. Exon Smith via llvm-dev]

> 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.
>