[llvm-bugs] [Bug 39853] New: [CodeView] symbol records point to forward decls instead of full decls

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39853

            Bug ID: 39853
           Summary: [CodeView] symbol records point to forward decls
                    instead of full decls
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: zturner at google.com
                CC: alexandre.ganea at ubisoft.com, jdevlieghere at apple.com,
                    keith.walker at arm.com, llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com, rnk at google.com

We seem to have a general problem where symbol records such as S_UDT,
S_GDATA32, S_LDATA32, and perhaps others have type indices that point to
forward declarations.

We should make these point to full decls to match the behavior of MSVC.

It's interesting that we found this, because it reminds me of something
Alexandre Ganea said to me at the LLVM developer conference.  Which is that
when you add a variable in the watch window and expand it, the first time it
can be very slow, maybe a couple of seconds.  But if you use MSVC to compile,
this slowdown doesn't exist.

This seems like a plausible explanation for this.  If MSVC follows your
TypeIndex and finds a forward decl, it has to scan for the full decl itself,
and these are potentially many many records apart in the type stream.  However,
once it finds it the first time, it could maintain its own internal map and not
have to translate it again.

So I'm hypothesizing that fixing this may fix Alexander's problem as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181201/654821a7/attachment.html>