summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [codeview] Let the X86 backend tell us the VFRAME offset adjustmentReid Kleckner2018-11-031-8/+3
| | | | | | | | | | | Use MachineFrameInfo's OffsetAdjustment field to pass this information from the target to CodeViewDebug.cpp. The X86 backend doesn't use it for any other purpose. This fixes PR38857 in the case where there is a non-aligned quantity of CSRs and a non-aligned quantity of locals. llvm-svn: 346062
* [CodeView] Emit the correct TypeIndex for std::nullptr_t.Zachary Turner2018-11-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | The TypeIndex used by cl.exe is 0x103, which indicates a SimpleTypeMode of NearPointer (note the absence of the bitness, normally pointers use a mode of NearPointer32 or NearPointer64) and a SimpleTypeKind of void. So this is basically a void*, but without a specified size, which makes sense given how std::nullptr_t is defined. clang-cl was actually not emitting *anything* for this. Instead, when we encountered std::nullptr_t in a DIType, we would actually just emit a TypeIndex of 0, which is obviously wrong. std::nullptr_t in DWARF is represented as a DW_TAG_unspecified_type with a name of "decltype(nullptr)", so we add that logic along with a test, as well as an update to the dumping code so that we no longer print void* when dumping 0x103 (which would previously treat Void/NearPointer no differently than Void/NearPointer64). Differential Revision: https://reviews.llvm.org/D53957 llvm-svn: 345811
* MachineModuleInfo: Initialize DbgInfoAvailable depending on debug_cus existingMatthias Braun2018-10-311-0/+1
| | | | | | | | | | | | | | | | Before this patch DbgInfoAvailable was set to true in DwarfDebug::beginModule() or CodeViewDebug::CodeViewDebug(). This made MIR testing weird since passes would suddenly stop dealing with debug info just because we stopped the pipeline before the debug printers. This patch changes the logic to initialize DbgInfoAvailable based on the fact that debug_compile_units exist in the llvm Module. The debug printers may then override it with false in case of debug printing being disabled. Differential Revision: https://reviews.llvm.org/D53885 llvm-svn: 345740
* [codeview] Emit S_BUILDINFO and LF_BUILDINFO with cwd and source fileReid Kleckner2018-10-121-0/+48
| | | | | | | | | | | | Summary: We can fill in the command line and compiler path later if we want. Reviewers: zturner Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D53179 llvm-svn: 344393
* Better support for POSIX paths in PDBs.Zachary Turner2018-10-121-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This a resubmission of a patch which was previously reverted due to breaking several lld tests. The issues causing those failures have been fixed, so the patch is now resubmitted. ---Original Commit Message--- While it doesn't make a *ton* of sense for POSIX paths to be in PDBs, it's possible to occur in real scenarios involving cross compilation. The tools need to be able to handle this, because certain types of debugging scenarios are possible without a running process and so don't necessarily require you to be on a Windows system. These include post-mortem debugging and binary forensics (e.g. using a debugger to disassemble functions and examine symbols without running the process). There's changes in clang, LLD, and lldb in this patch. After this the cross-platform disassembly and source-list tests pass on Linux. Furthermore, the behavior of LLD can now be summarized by a much simpler rule than before: Unless you specify /pdbsourcepath and /pdbaltpath, the PDB ends up with paths that are valid within the context of the machine that the link is performed on. Differential Revision: https://reviews.llvm.org/D53149 llvm-svn: 344377
* Revert SymbolFileNativePDB plugin.Zachary Turner2018-10-111-4/+1
| | | | | | | | | This was originally causing some test failures on non-Windows platforms, which required fixes in the compiler and linker. After those fixes, however, other tests started failing. Reverting temporarily until I can address everything. llvm-svn: 344279
* Better support for POSIX paths in PDBs.Zachary Turner2018-10-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | While it doesn't make a *ton* of sense for POSIX paths to be in PDBs, it's possible to occur in real scenarios involving cross compilation. The tools need to be able to handle this, because certain types of debugging scenarios are possible without a running process and so don't necessarily require you to be on a Windows system. These include post-mortem debugging and binary forensics (e.g. using a debugger to disassemble functions and examine symbols without running the process). There's changes in clang, LLD, and lldb in this patch. After this the cross-platform disassembly and source-list tests pass on Linux. Furthermore, the behavior of LLD can now be summarized by a much simpler rule than before: Unless you specify /pdbsourcepath and /pdbaltpath, the PDB ends up with paths that are valid within the context of the machine that the link is performed on. Differential Revision: https://reviews.llvm.org/D53149 llvm-svn: 344269
* [CodeView] Only add the Scoped flag for an enum type when it has an ↵Aaron Smith2018-10-021-5/+13
| | | | | | | | | | | | immediate function scope to match MSVC Reviewers: rnk, zturner, llvm-commits Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D52706 llvm-svn: 343627
* [CodeView] Emit function options for subprogram and member functionsAaron Smith2018-10-021-8/+40
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use the newly added DebugInfo (DI) Trivial flag, which indicates if a C++ record is trivial or not, to determine Codeview::FunctionOptions. Clang and MSVC generate slightly different Codeview for C++ records. For example, here is the C++ code for a class with a defaulted ctor, class C { public: C() = default; }; Clang will produce a LF for the defaulted ctor while MSVC does not. For more details, refer to FIXMEs in the test cases in "function-options.ll" included with this set of changes. Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov Reviewed By: rnk Subscribers: Hui, JDevlieghere Differential Revision: https://reviews.llvm.org/D45123 llvm-svn: 343626
* [codeview] Fix 32-bit x86 variable locations in realigned stack framesReid Kleckner2018-10-021-4/+10
| | | | | | | | | | | | | | | | | | Add the .cv_fpo_stackalign directive so that we can define $T0, or the VFRAME virtual register, with it. This was overlooked in the initial implementation because unlike MSVC, we push CSRs before allocating stack space, so this value is only needed to describe local variable locations. Variables that the compiler now addresses via ESP are instead described as being stored at offsets from VFRAME, which for us is ESP after alignment in the prologue. This adds tests that show that we use the VFRAME register properly in our S_DEFRANGE records, and that we emit the correct FPO data to define it. Fixes PR38857 llvm-svn: 343603
* [codeview] Simplify S_DEFRANGE emission code, NFCReid Kleckner2018-10-011-30/+22
| | | | | | | These assembler directives are still pretty unreadable and it would be nice to clean them up at some point. llvm-svn: 343544
* [codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_RELReid Kleckner2018-10-011-40/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, LLVM would always describe locals on the stack as being relative to some specific register, RSP, ESP, EBP, ESI, etc. Variables in stack memory are pretty common, so there is a special S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to reduce the size of our debug info. On top of the size savings, there are cases on 32-bit x86 where local variables are addressed from ESP, but ESP changes across the function. Unlike in DWARF, there is no FPO data to describe the stack adjustments made to push arguments onto the stack and pop them off after the call, which makes it hard for the debugger to find the local variables in frames further up the stack. To handle this, CodeView has a special VFRAME register, which corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets to local variables are instead relative to this value. This is part of PR38857. Reviewers: hans, zturner, javed.absar Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D52217 llvm-svn: 343543
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-4/+3
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [codeview] Remove dead codeReid Kleckner2018-09-141-13/+0
| | | | llvm-svn: 342285
* [DebugInfo] Do not generate label debug info if it has been processed.Hsiangkai Wang2018-09-061-5/+5
| | | | | | | | In DwarfDebug::collectEntityInfo(), if the label entity is processed in DbgLabels list, it means the label is not optimized out. There is no need to generate debug info for it with null position. llvm-svn: 341513
* [CodeView] Omit forward references for unnamed structs and unionsBrock Wyma2018-06-111-10/+40
| | | | | | | | | | Codeview references to unnamed structs and unions are expected to refer to the complete type definition instead of a forward reference so Visual Studio can resolve the type properly. Differential Revision: https://reviews.llvm.org/D32498 llvm-svn: 334382
* Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-2/+2
| | | | | | | This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676
* Revert "[pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-2/+2
| | | | | | | A few tests haven't been properly updated, so reverting while I have time to investigate proper fixes. llvm-svn: 332672
* [pdb] Change /DEBUG:GHASH to emit 8 byte hashes.Zachary Turner2018-05-171-2/+2
| | | | | | | | | | | | | | | | Previously we emitted 20-byte SHA1 hashes. This is overkill for identifying debug info records, and has the negative side effect of making object files bigger and links slower. By using only the last 8 bytes of a SHA1, we get smaller object files and ~10% faster links. This modifies the format of the .debug$H section by adding a new value for the hash algorithm field, so that the linker will still work when its object files have an old format. Differential Revision: https://reviews.llvm.org/D46855 llvm-svn: 332669
* [CodeView] Improve debugging of virtual base class member variablesBrock Wyma2018-05-141-2/+1
| | | | | | | | Initial support for passing the virtual base pointer offset to CodeViewDebug. https://reviews.llvm.org/D46271 llvm-svn: 332296
* [DebugInfo] Examine all uses of isDebugValue() for debug instructions.Shiva Chen2018-05-091-3/+3
| | | | | | | | | | | | | | | | | | Because we create a new kind of debug instruction, DBG_LABEL, we need to check all passes which use isDebugValue() to check MachineInstr is debug instruction or not. When expelling debug instructions, we should expel both DBG_VALUE and DBG_LABEL. So, I create a new function, isDebugInstr(), in MachineInstr to check whether the MachineInstr is debug instruction or not. This patch has no new test case. I have run regression test and there is no difference in regression test. Differential Revision: https://reviews.llvm.org/D45342 Patch by Hsiangkai Wang. llvm-svn: 331844
* [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...Brock Wyma2018-04-161-1/+58
| | | | | | | | | | | When emitting CodeView debug information, compiler-generated thunk routines should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so Visual Studio can properly step into the user code. This initial support only handles standard thunk ordinals. Differential Revision: https://reviews.llvm.org/D43838 llvm-svn: 330132
* CodeGen: Don't try to canonicalize Unix-style paths in CodeView debug info.Peter Collingbourne2018-04-111-0/+10
| | | | | | | | | Most importantly, we should not replace slashes with backslashes because that would invalidate the path. Differential Revision: https://reviews.llvm.org/D45473 llvm-svn: 329838
* [Debuginfo][COFF] Minimal serialization support for precompiled types recordsAlexandre Ganea2018-04-091-1/+1
| | | | | | | | | | | | | This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required to read/write Microsoft precompiled types .objs. See https://en.wikipedia.org/wiki/Precompiled_header#Microsoft_Visual_C_and_C++ This also adds handling for the .debug$P section, which is actually a .debug$T section in disguise, found only in precompiled .objs. Differential Revision: https://reviews.llvm.org/D45283 llvm-svn: 329613
* [CodeGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: bogner, rnk, MatzeB, RKSimon Reviewed By: rnk Subscribers: JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D45133 llvm-svn: 329435
* Move TargetLoweringObjectFile from CodeGen to Target to fix layeringDavid Blaikie2018-03-231-1/+1
| | | | | | | It's implemented in Target & include from other Target headers, so the header should be in Target. llvm-svn: 328392
* Re-land r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-151-6/+141
| | | | | | | | | for lexical scopes" This is safe to land now that we don't copy FunctionInfo when rehashing the DenseMap. llvm-svn: 327670
* [codeview] Fix sense of the assertion about hashtable insertionReid Kleckner2018-03-151-1/+1
| | | | llvm-svn: 327669
* [codeview] Delete FunctionInfo copy ctor and move out of DenseMapReid Kleckner2018-03-151-4/+5
| | | | | | | | | | | | | We were unnecessarily copying a bunch of these FunctionInfo objects around when rehashing the DenseMap. Furthermore, r327620 introduced pointers referring to objects owned by FunctionInfo, and the default copy ctor did the wrong thing in this case, leading to use-after-free when the DenseMap gets rehashed. I will rebase r327620 on this next and recommit it. llvm-svn: 327665
* Revert r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-151-138/+6
| | | | | | | | | | for lexical scopes" It is causing crashes when compiling Chrome in debug mode. I'll try to debug it in a second. llvm-svn: 327657
* [CodeView] Initial support for emitting S_BLOCK32 symbols for lexical scopesBrock Wyma2018-03-151-6/+138
| | | | | | | | | This patch sorts local variables by lexical scope and emits them inside an appropriate S_BLOCK32 CodeView symbol. Differential Revision: https://reviews.llvm.org/D42926 llvm-svn: 327620
* TargetMachine: Add address space to getPointerSizeMatt Arsenault2018-03-141-3/+3
| | | | llvm-svn: 327467
* Revert r327397 [CodeView] Omit forward references for unnamed structs and ...Brock Wyma2018-03-131-40/+10
| | | | | | This reverts commit r327397 to investigate a buildbot failure. llvm-svn: 327414
* [CodeView] Omit forward references for unnamed structs and unionsBrock Wyma2018-03-131-10/+40
| | | | | | | | | | Codeview references to unnamed structs and unions are expected to refer to the complete type definition instead of a forward reference so Visual Studio can resolve the type properly. Differential Revision: https://reviews.llvm.org/D32498 llvm-svn: 327397
* [SelectionDAG] Improve handling of dangling debug infoBjorn Pettersson2018-03-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 1) Make sure to discard dangling debug info if the variable (or variable fragment) is mapped to something new before we had a chance to resolve the dangling debug info. 2) When resolving debug info, make sure to bump the associated SDNodeOrder to ensure that the DBG_VALUE is emitted after the instruction that defines the value used in the DBG_VALUE. This will avoid a debug-use before def scenario as seen in https://bugs.llvm.org/show_bug.cgi?id=36417. The new test case, test/DebugInfo/X86/sdag-dangling-dbgvalue.ll, show some other limitations in how dangling debug info is handled in the SelectionDAG. Since we currently only support having one dangling dbg.value per Value, we will end up dropping debug info when there are more than one variable that is described by the same "dangling value". Reviewers: aprantl Reviewed By: aprantl Subscribers: aprantl, eraman, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44369 llvm-svn: 327303
* [CodeView] Emit UdtSourceLine information for enumsAaron Smith2018-03-061-13/+27
| | | | | | | | | | | | | | | | | Summary: - Emit UdtSourceLine information for enums to match MSVC - Add a method to add UDTSrcLine and call it for all Class/Struct/Union/Enum - Update test cases to verify the changes Reviewers: zturner, llvm-commits, rnk Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D44116 llvm-svn: 326824
* [CodeView] Lower __restrict and other pointer qualifiers correctlyReid Kleckner2018-02-271-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualifiers on a pointer or reference type may apply to either the pointee or the pointer itself. Consider 'const char *' and 'char * const'. In the first example, the pointee data may not be modified without casts, and in the second example, the pointer may not be updated to point to new data. In the general case, qualifiers are applied to types with LF_MODIFIER records, which support the usual const and volatile qualifiers as well as the __unaligned extension qualifier. However, LF_POINTER records, which are used for pointers, references, and member pointers, have flags for qualifiers applying to the *pointer*. In fact, this is the only way to represent the restrict qualifier, which can only apply to pointers, and cannot qualify regular data types. This patch causes LLVM to correctly fold 'const' and 'volatile' pointer qualifiers into the pointer record, as well as adding support for '__restrict' qualifiers in the same place. Based on a patch from Aaron Smith Differential Revision: https://reviews.llvm.org/D43060 llvm-svn: 326260
* [AsmPrinter] Handle qualified unnamed types in CodeView printerShoaib Meenai2018-02-271-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When attempting to compile the following Objective-C++ code with CodeView debug info: void (^b)(void) = []() {}; The generated debug metadata contains a structure like the following: !43 = !DICompositeType(tag: DW_TAG_structure_type, name: "__block_literal_1", scope: !6, file: !6, line: 1, size: 168, elements: !44) !44 = !{!45, !46, !47, !48, !49, !52} ... !52 = !DIDerivedType(tag: DW_TAG_member, scope: !6, file: !6, line: 1, baseType: !53, size: 8, offset: 160, flags: DIFlagPublic) !53 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !54) !54 = !DICompositeType(tag: DW_TAG_class_type, file: !6, line: 1, flags: DIFlagFwdDecl) Note that the member node (!52) is unnamed, but rather than pointing to a DICompositeType directly, it points to a DIDerivedType with tag DW_TAG_const_type, which then points to the DICompositeType. However, the CodeView assembly printer currently assumes that the base type for an unnamed member will always be a DICompositeType, and attempts to perform that cast, which triggers an assertion failure, since in this case the base type is actually a DIDerivedType, not a DICompositeType (and we would have to get the base type of the DIDerivedType to reach the DICompositeType). I think the debug metadata being generated by the frontend is correct (or at least plausible), and the CodeView printer needs to handle this case. This patch teaches the CodeView printer to unwrap any qualifier types. The qualifiers are just dropped for now. Ideally, they would be applied to the added indirect members instead, but this occurs infrequently enough that adding the logic to handle the qualifiers correctly isn't worth it for now. A FIXME is added to note this. Additionally, Reid pointed out that the underlying assumption that an unnamed member must be a composite type is itself incorrect and may not hold for all frontends. Therefore, after all qualifiers have been stripped, check if the resulting type is in fact a DICompositeType and just return if it isn't, rather than assuming the type and crashing if that assumption is violated. Differential Revision: https://reviews.llvm.org/D43803 llvm-svn: 326255
* [DebugInfo] Unify ChecksumKind and Checksum value in DIFileScott Linder2018-02-121-7/+14
| | | | | | | | | Rather than encode the absence of a checksum with a Kind variant, instead put both the kind and value in a struct and wrap it in an Optional. Differential Revision: http://reviews.llvm.org/D43043 llvm-svn: 324928
* [CodeView] Allow variable names to be as long as the codeview format supportsBrock Wyma2018-02-111-3/+4
| | | | | | | | | Instead of reserving 0xF00 bytes for the fixed length portion of the CodeView symbol name, calculate the actual length of the fixed length portion. Differential Revision: https://reviews.llvm.org/D42125 llvm-svn: 324850
* [CodeView] Class record member counts should include base classes and ...Brock Wyma2018-02-011-0/+2
| | | | | | | | | Increment the field list member count for base classes and virtual base classes. Differential Revision: https://reviews.llvm.org/D41874 llvm-svn: 324000
* Test commit.Brock Wyma2018-01-301-2/+2
| | | | | | As per the LLVM Developer Policy under "Obtainiing Commit Access". llvm-svn: 323754
* [Metadata] Extend 'count' field of DISubrange to take a metadata nodeSander de Smalen2018-01-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch extends the DISubrange 'count' field to take either a (signed) constant integer value or a reference to a DILocalVariable or DIGlobalVariable. This is patch [1/3] in a series to extend LLVM's DISubrange Metadata node to support debugging of C99 variable length arrays and vectors with runtime length like the Scalable Vector Extension for AArch64. It is also a first step towards representing more complex cases like arrays in Fortran. Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: rnk, probinson, fhahn, aemerson, rengolin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41695 llvm-svn: 323313
* [CodeView] Fix the type for a variadic argumentAaron Smith2018-01-111-0/+12
| | | | | | | | | | | | | | Summary: - MSVC uses the none type for a variadic argument in CodeView - Add a unit test Reviewers: zturner, llvm-commits Reviewed By: zturner Differential Revision: https://reviews.llvm.org/D41931 llvm-svn: 322257
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-8/+8
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* [CodeView] Teach clang to emit the .debug$H COFF section.Zachary Turner2017-12-131-7/+44
| | | | | | | | | | | | | | | Currently this is an LLVM extension to the COFF spec which is experimental and intended to speed up linking. For now it is behind a hidden cl::opt flag, but in the future we can move it to a "real" cc1 flag and have the driver pass it through whenever it is appropriate. The patch to actually make use of this section in lld will come in a followup. Differential Revision: https://reviews.llvm.org/D40917 llvm-svn: 320649
* [CodeView] Refactor / Rewrite TypeSerializer and TypeTableBuilder.Zachary Turner2017-11-281-45/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation behind this patch is that future directions require us to be able to compute the hash value of records independently of actually using them for de-duplication. The current structure of TypeSerializer / TypeTableBuilder being a single entry point that takes an unserialized type record, and then hashes and de-duplicates it is not flexible enough to allow this. At the same time, the existing TypeSerializer is already extremely complex for this very reason -- it tries to be too many things. In addition to serializing, hashing, and de-duplicating, ti also supports splitting up field list records and adding continuations. All of this functionality crammed into this one class makes it very complicated to work with and hard to maintain. To solve all of these problems, I've re-written everything from scratch and split the functionality into separate pieces that can easily be reused. The end result is that one class TypeSerializer is turned into 3 new classes SimpleTypeSerializer, ContinuationRecordBuilder, and TypeTableBuilder, each of which in isolation is simple and straightforward. A quick summary of these new classes and their responsibilities are: - SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of bytes. Does not do any hashing. Every time you call it, it will re-serialize and return bytes again. The same instance can be re-used over and over to avoid re-allocations, and in exchange for this optimization the bytes returned by the serializer only live until the caller attempts to serialize a new record. - ContinuationRecordBuilder : Turns a FieldList-like record into a series of fragments. Does not do any hashing. Like SimpleTypeSerializer, returns references to privately owned bytes, so the storage is invalidated as soon as the caller tries to re-use the instance. Works equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a long-standing theoretical limitation of the previous implementation. - TypeTableBuilder : Accepts sequences of bytes that the user has already serialized, and inserts them by de-duplicating with a hash table. For the sake of convenience and efficiency, this class internally stores a SimpleTypeSerializer so that it can accept unserialized records. The same is not true of ContinuationRecordBuilder. The user is required to create their own instance of ContinuationRecordBuilder. Differential Revision: https://reviews.llvm.org/D40518 llvm-svn: 319198
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-6/+6
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* Move TargetFrameLowering.h to CodeGen where it's implementedDavid Blaikie2017-11-031-1/+1
| | | | | | | | | | | This header already includes a CodeGen header and is implemented in lib/CodeGen, so move the header there to match. This fixes a link error with modular codegeneration builds - where a header and its implementation are circularly dependent and so need to be in the same library, not split between two like this. llvm-svn: 317379
* [codeview] Merge file checksum entries for DIFiles with the same absolute pathReid Kleckner2017-10-311-2/+2
| | | | | | | | Change the map key from DIFile* to the absolute path string. Computing the absolute path isn't expensive because we already have a map that caches the full path keyed on DIFile*. llvm-svn: 317041
OpenPOWER on IntegriCloud