llvm dev - Feb 2019 - Scope for DILocalVariables describing parameters?

Hi!

Is it valid to assume that the scope for a parameter-describing
DILocalVariable always is a DISubprogram? Or do you know of any case
where a parameter's scope can be a sub-scope of the DISubprogram?

I added a check to the IR verifier and an assertion to
DIBuilder::createParameterVariable() that verify this. This resulted in
one test case, DebugInfo/X86/double-declare.ll, failing when running
check-all:

parameter requires subprogram scope
!7 = !DILocalVariable(name: "aRect", arg: 1, scope: !8, file: !1,
line:
38, type: !11)
!8 = distinct !DILexicalBlock(scope: !9, file: !1, line: 38)

However, if I rerun the clang command mentioned in the referenced PR
(PR33157), the parameter's scope becomes the subprogram:

!68 = !DILocalVariable(name: "aRect", arg: 1, scope: !63, file: !5,
line: 27, type: !66
!63 = distinct !DISubprogram(name: "NSMaxX"

so I suspect that might simply be an artifact from bugpointing or
manual reduction of the IR.

Best regards,
David

> On Feb 8, 2019, at 4:14 AM, David Stenberg via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi!
> 
> Is it valid to assume that the scope for a parameter-describing
> DILocalVariable always is a DISubprogram? Or do you know of any case
> where a parameter's scope can be a sub-scope of the DISubprogram?
I believe that for the Clang and Swift frontends that should always be true. A
hypothetical language frontend for a language that supports functions with
multiple entry points might be a counterexample, but I don't know of any.
> I added a check to the IR verifier and an assertion to
> DIBuilder::createParameterVariable() that verify this. This resulted in
> one test case, DebugInfo/X86/double-declare.ll, failing when running
> check-all:
> 
> parameter requires subprogram scope
> !7 = !DILocalVariable(name: "aRect", arg: 1, scope: !8, file: !1,
line:
> 38, type: !11)
> !8 = distinct !DILexicalBlock(scope: !9, file: !1, line: 38)
> 
> However, if I rerun the clang command mentioned in the referenced PR
> (PR33157), the parameter's scope becomes the subprogram:
> 
> !68 = !DILocalVariable(name: "aRect", arg: 1, scope: !63, file:
!5,
> line: 27, type: !66
> !63 = distinct !DISubprogram(name: "NSMaxX"
> 
> so I suspect that might simply be an artifact from bugpointing or
> manual reduction of the IR.
That, or older, buggy versions of clang.

-- adrian

> > Is it valid to assume that the scope for a parameter-describing
> > DILocalVariable always is a DISubprogram? Or do you know of any case
> > where a parameter's scope can be a sub-scope of the DISubprogram?
> 
> I believe that for the Clang and Swift frontends that should always be
> true. A hypothetical language frontend for a language that supports
> functions with multiple entry points might be a counterexample, but I
> don't know of any.
FORTRAN and PL/I both support multiple entrypoints, to my knowledge,
although I am pretty sure in PL/I this does *not* introduce a new scope.
Don't know about FORTRAN.  I think there's a Flang project with its own
mailing list?  People there might know.
--paulr