search for: pr33157

...k it's a bug in both places: the backend should tolerate identical, duplicate dbg.declares, and the loop unroller probably shouldn't duplicate dbg.declare, since there is no point. IR is supposed to be duplicatable unless it is marked noduplicate. That was ultimately the fix we applied for PR33157, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170919/dea4904b/attachment.html>

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

...te identical, duplicate dbg.declares, I guess that's fair, yes. -- adrian > and the loop unroller probably shouldn't duplicate dbg.declare, since there is no point. > > IR is supposed to be duplicatable unless it is marked noduplicate. That was ultimately the fix we applied for PR33157, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170919/30276e95/attachment.html>

> On Sep 19, 2017, at 6:33 AM, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Björn, > > I don't have any answers, just more confusion. Hopefully someone else can bring some light to this. > > I'm also interested in dbg.declares and what the rules are regarding them since it's not very clear to me at the moment. A dbg.declare

...that's fair, yes. > > -- adrian > >> and the loop unroller probably shouldn't duplicate dbg.declare, since >> there is no point. >> >> IR is supposed to be duplicatable unless it is marked noduplicate. >> That was ultimately the fix we applied for PR33157, right? >