summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-1/+1
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-047-64/+93
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-041-2/+1
| | | | | | | | | | | | | | instructions within a function, lead to the function itself." Originally reverted in r213432 with flakey failures on an ASan self-host build. After reduction it seems to be the same issue fixed in r213805 (ArgPromo + DebugInfo: Handle updating debug info over multiple applications of argument promotion) and r213952 (by having LiveDebugVariables strip dbg_value intrinsics in functions that are not described by debug info). Though I cannot explain why this failure was flakey... llvm-svn: 214761
* Attempt to increase the overall happiness of the MSCV-based buildbots.Adrian Prantl2014-08-011-1/+1
| | | | llvm-svn: 214588
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-019-73/+301
| | | | | | | | | | | | | | | | | | | | | | | | variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. llvm-svn: 214576
* Refactor duplicated code.Rafael Espindola2014-07-301-24/+2
| | | | llvm-svn: 214328
* Add the missing hasLinkOnceODRLinkage predicate.Rafael Espindola2014-07-301-2/+1
| | | | llvm-svn: 214312
* Feedback on r214189, no functionality change.Manman Ren2014-07-292-2/+2
| | | | llvm-svn: 214240
* [Debug Info] remove DITrivialType and use null to represent unspecified param.Manman Ren2014-07-292-5/+7
| | | | | | | | | | | | Per feedback on r214111, we are going to use null to represent unspecified parameter. If the type array is {null}, it means a function that returns void; If the type array is {null, null}, it means a variadic function that returns void. In summary if we have more than one element in the type array and the last element is null, it is a variadic function. rdar://17628609 llvm-svn: 214189
* [Debug Info] unique MDNodes in the enum types of each compile unit.Manman Ren2014-07-281-2/+7
| | | | | | | | | The enum types array by design contains pointers to MDNodes rather than DIRefs. Unique them when handling the enum types in DwarfDebug. rdar://17628609 llvm-svn: 214139
* [Debug Info] add DISubroutineType and its creation takes DITypeArray. Manman Ren2014-07-283-12/+12
| | | | | | | | | | | DITypeArray is an array of DITypeRef, at its creation, we will create DITypeRef (i.e use the identifier if the type node has an identifier). This is the last patch to unique the type array of a subroutine type. rdar://17628609 llvm-svn: 214132
* [Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.Manman Ren2014-07-282-8/+8
| | | | | | | | | | | | | | | This is the second of a series of patches to handle type uniqueing of the type array for a subroutine type. For vector and array types, getElements returns the array of subranges, so it is a better name than getTypeArray. Even for class, struct and enum types, getElements returns the members, which can be subprograms. setArrays can set up to two arrays, the second is the templates. This commit should have no functionality change. llvm-svn: 214112
* Reapply "DebugInfo: Don't put fission type units in comdat sections."David Blaikie2014-07-253-12/+19
| | | | | | | | | | | | | | | | This recommits r208930, r208933, and r208975 (by reverting r209338) and reverts r209529 (the FIXME to readd this functionality once the tools were fixed) now that DWP has been fixed to cope with a single section for all fission type units. Original commit message: "Since type units in the dwo file are handled by a debug aware tool, they don't need to leverage the ELF comdat grouping to implement deduplication. Avoid creating all the .group sections for these as a space optimization." llvm-svn: 213956
* Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie2014-07-252-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. This was then reverted again in r213581 as it caused PR20367. The root cause of this was the early exit in LiveDebugVariables meant that spurious DBG_VALUE intrinsics that referenced dead variables were not removed, causing an assertion/crash later on. The fix is to have LiveDebugVariables strip all DBG_VALUE intrinsics in functions without debug info as they're not needed anyway. Test case added to cover this situation (that occurs when a debug-having function is inlined into a nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 213952
* [X86] Optimize stackmap shadows on X86.Lang Hames2014-07-241-0/+2
| | | | | | | | | | | | | | | | | | | This patch minimizes the number of nops that must be emitted on X86 to satisfy stackmap shadow constraints. To minimize the number of nops inserted, the X86AsmPrinter now records the size of the most recent stackmap's shadow in the StackMapShadowTracker class, and tracks the number of instruction bytes emitted since the that stackmap instruction was encountered. Padding is emitted (if it is required at all) immediately before the next stackmap/patchpoint instruction, or at the end of the basic block. This optimization should reduce code-size and improve performance for people using the llvm stackmap intrinsic on X86. <rdar://problem/14959522> llvm-svn: 213892
* Revert "Recommit r212203: Don't try to construct debug LexicalScopes ↵David Blaikie2014-07-212-18/+1
| | | | | | | | hierarchy for functions that do not have top level debug information." This reverts commit r212649 while I investigate/reduce/etc PR20367. llvm-svn: 213581
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵Eric Christopher2014-07-181-1/+2
| | | | | | | | | | instructions within a function, lead to the function itself."""" After a successful build it seems to have come back on a later build. This reverts commit r213391. llvm-svn: 213432
* DebugInfo: Assert that all abstract scopes are subprograms, rather than ↵David Blaikie2014-07-181-2/+1
| | | | | | | | conditionalizing. There's nothing else these should ever be... llvm-svn: 213417
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-181-2/+1
| | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself.""" Recommits 212776 which was reverted in r212793. This has been committed and recommitted a few times as I try to test it harder and find/fix more issues. The most recent revert was due to an asan bot failure which I can't seem to reproduce locally, though I believe I'm following all the steps the buildbot does. So I'm going to recommit this in the hopes of investigating the failure on the buildbot itself... apologies in advance for the bot noise. If anyone sees failures with this /please/ provide me with any reproductions, etc. llvm-svn: 213391
* CodeGen: Stick constant pool entries in COMDAT sections for WinCOFFDavid Majnemer2014-07-141-7/+21
| | | | | | | | | | | | | | | | COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
* CodeGen: Add a getSectionKind method to MachineConstantPoolEntryDavid Majnemer2014-07-141-15/+1
| | | | | | This is just a helper routine, no functionality has changed. llvm-svn: 212993
* CodeGen: add missing includeSaleem Abdulrasool2014-07-141-0/+1
| | | | | | | Found during windows unwinding work. This header is indirectly included through a chain leading through Support/Win64EH.h. Explicitly include the header. NFC. llvm-svn: 212955
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-111-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r212776. Nope, still seems to be failing on the sanitizer bots... but hey, not the msan self-host anymore, it's failing in asan now. I'll start looking there next. llvm-svn: 212793
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself." Committed in r212205 and reverted in r212226 due to msan self-hosting failure, I believe I've got that fixed by r212761 to Clang. Original commit message: "Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions." llvm-svn: 212776
* Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie2014-07-092-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212649
* Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for ↵Eric Christopher2014-07-032-11/+1
| | | | | | | | functions that do not have top level debug information." as it appears to be breaking some LTO constructs. This reverts commit r212203. llvm-svn: 212298
* Fix ppcf128 component access on little-endian systemsUlrich Weigand2014-07-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PowerPC 128-bit long double data type (ppcf128 in LLVM) is in fact a pair of two doubles, where one is considered the "high" or more-significant part, and the other is considered the "low" or less-significant part. When a ppcf128 value is stored in memory or a register pair, the high part always comes first, i.e. at the lower memory address or in the lower-numbered register, and the low part always comes second. This is true both on big-endian and little-endian PowerPC systems. (Similar to how with a complex number, the real part always comes first and the imaginary part second, no matter the byte order of the system.) This was implemented incorrectly for little-endian systems in LLVM. This commit fixes three related issues: - When printing an immediate ppcf128 constant to assembler output in emitGlobalConstantFP, emit the high part first on both big- and little-endian systems. - When lowering a ppcf128 type to a pair of f64 types in SelectionDAG (which is used e.g. when generating code to load an argument into a register pair), use correct low/high part ordering on little-endian systems. - In a related issue, because lowering ppcf128 into a pair of f64 must operate differently from lowering an int128 into a pair of i64, bitcasts between ppcf128 and int128 must not be optimized away by the DAG combiner on little-endian systems, but must effect a word-swap. Reviewed by Hal Finkel. llvm-svn: 212274
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-021-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself." This reverts commit r212205. Reverting this again, still seeing crashes when building compiler-rt... Sorry for the continued noise, not sure why I'm failing to reproduce this locally. llvm-svn: 212226
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-021-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | within a function, lead to the function itself. Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 212205
* Don't try to construct debug LexicalScopes hierarchy for functions that do ↵David Blaikie2014-07-022-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | not have top level debug information. If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212203
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-011-1/+2
| | | | | | | | | | | instructions within a function, lead to the function itself." This reverts commit r212085. This breaks the sanitizer bot... & I thought I'd tried pretty hard not to do that. Guess I need to try harder. llvm-svn: 212089
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | within a function, lead to the function itself. Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), and I now believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 212085
* CodeGen: rename Win64 ExceptionHandling to WinEHSaleem Abdulrasool2014-06-291-4/+3
| | | | | | | | | | This exception format is not specific to Windows x64. A similar approach is taken on nearly all architectures. Generalise the name to reflect reality. This will eventually be used for Windows on ARM data emission as well. Switch the enum and namespace into an enum class. llvm-svn: 212000
* MC: rename EmitWin64EH routinesSaleem Abdulrasool2014-06-291-4/+4
| | | | | | | | | | | | | | | Rename the routines to reflect the reality that they are more related to call frame information than to Win64 EH. Although EH is implemented in an intertwined manner by augmenting with an exception handler and an associated parameter, the majority of these routines emit information required to unwind the frames. This also helps identify that these routines are generic for most windows platforms (they apply equally to nearly all architectures except x86) although the encoding of the information is architecture dependent. Unwinding data is emitted via EmitWinCFI* and exception handling information via EmitWinEH*. llvm-svn: 211994
* Revert "Revert "Revert "PR20038: DebugInfo: Inlined call sites where the ↵David Blaikie2014-06-271-1/+2
| | | | | | | | | | | caller has debug info but the call itself has no debug location.""" Reverting this again, didn't mean to commit it - while r211872 fixes one of the issues here, there are still others to figure out and address. This reverts commit r211871. llvm-svn: 211873
* Revert "Revert "PR20038: DebugInfo: Inlined call sites where the caller has ↵David Blaikie2014-06-271-2/+1
| | | | | | | | debug info but the call itself has no debug location."" This reverts commit r211724. llvm-svn: 211871
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-262-5/+10
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-262-10/+5
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug ↵David Blaikie2014-06-251-1/+2
| | | | | | | | | | | info but the call itself has no debug location." This reverts commit r211723. Breaks the ASan/compiler-rt build... guess I didn't test very far at all :/. llvm-svn: 211724
* PR20038: DebugInfo: Inlined call sites where the caller has debug info but ↵David Blaikie2014-06-251-2/+1
| | | | | | | | | | | | | | | | | | the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 211723
* Re-apply r211399, "Generate native unwind info on Win64" with a fix to ↵NAKAMURA Takumi2014-06-251-10/+3
| | | | | | | | | | | | | | | | | | | | | | | ignore SEH pseudo ops in X86 JIT emitter. -- This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211691
* Print a=b as an assignment.Rafael Espindola2014-06-241-3/+11
| | | | | | | | | | | In assembly the expression a=b is parsed as an assignment, so it should be printed as one. This remove a truly horrible hack for producing a label with "a=.". It would be used by codegen but would never be reached by the asm parser. Sorry I missed this when it was first committed. llvm-svn: 211639
* Remove a temporary hack.Rafael Espindola2014-06-231-10/+0
| | | | | | | Amusingly this survived a lot longer than the CFI transition. We don't even support non-cfi assemblers any more. llvm-svn: 211498
* Revert r211399, "Generate native unwind info on Win64"NAKAMURA Takumi2014-06-221-3/+10
| | | | | | It broke Legacy JIT Tests on x86_64-{mingw32|msvc}, aka Windows x64. llvm-svn: 211480
* Add back functionality removed in r210497.Richard Trieu2014-06-211-2/+4
| | | | | | Instead of asserting, output a message stating that a null pointer was found. llvm-svn: 211430
* Generate native unwind info on Win64Reid Kleckner2014-06-201-10/+3
| | | | | | | | | | | | | | | | | | | | This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211399
* The count() function for STL datatypes returns unsigned, even where it'sYaron Keren2014-06-201-1/+1
| | | | | | | | | | | | | | | | | only 1/0 result like std::set. Some of the LLVM ADT already return unsigned count(), while others still return bool count(). In continuation to r197879, this patch modifies DenseMap, DenseSet, ScopedHashTable, ValueMap:: count() to return size_type instead of bool, 1 instead of true and 0 instead of false. size_type is typedef-ed locally within each class to size_t. http://reviews.llvm.org/D4018 Reviewed by dblaikie. llvm-svn: 211350
* DebugInfo: Fission: Ensure the address pool entries for location lists are ↵David Blaikie2014-06-191-1/+1
| | | | | | | | | emitted. The address pool was being emitted before location lists. The latter could add more entries to the pool which would be lost/never emitted. llvm-svn: 211284
* Emit DWARF3 call frame information when DWARF3+ debug info is requestedOliver Stannard2014-06-191-0/+2
| | | | | | | | | | | | | | | | Currently, llvm always emits a DWARF CIE with a version of 1, even when emitting DWARF 3 or 4, which both support CIE version 3. This patch makes it emit the newer CIE version when we are emitting DWARF 3 or 4. This will not reduce compatibility, as we already emit other DWARF3/4 features, and is worth doing as the DWARF3 spec removed some ambiguities in the interpretation of call frame information. It also fixes a minor bug where the "return address" field of the CIE was encoded as a ULEB128, which is only valid when the CIE version is 3. There are no test changes for this, because (as far as I can tell) none of the platforms that we test have a return address register with a DWARF register number >127. llvm-svn: 211272
* Move -dwarf-version to an MC level command line option so it'sEric Christopher2014-06-191-4/+1
| | | | | | | used by all of the MC level tools and codegen. Fix up all uses in the compiler to use this and set it on the context accordingly. llvm-svn: 211257
OpenPOWER on IntegriCloud