summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* CodeGen: support SwiftError SwiftCC on Windows x64Saleem Abdulrasool2017-09-201-0/+2
| | | | | | | | | | Add support for passing SwiftError through a register on the Windows x64 calling convention. This allows the use of swifterror attributes on parameters which is used by the swift front end for the `Error` parameter. This partially enables building the swift standard library for Windows x86_64. llvm-svn: 313791
* Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"Reid Kleckner2017-09-201-40/+72
| | | | | | | | | | | | | After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
* [DebugInfo] Use a MapVector to coalesce MachineOperand locationsReid Kleckner2017-09-201-56/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new code should be linear in the number of DBG_VALUEs, while the old code was quadratic. NFC intended. This is also hopefully a more direct expression of the problem, which is to: 1. Rewrite all virtual register operands to stack slots or physical registers 2. Uniquely number those machine operands, assigning them location numbers 3. Rewrite all uses of the old location numbers in the interval map to use the new location numbers In r313400, I attempted to track which locations were spilled in a parallel bitvector indexed by location number. My code was broken because these location numbers are not stable during rewriting. Reviewers: aprantl, hans Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D38068 llvm-svn: 313775
* Recommit [MachineCombiner] Update instruction depths incrementally for large ↵Florian Hahn2017-09-202-23/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BBs. This version of the patch fixes an off-by-one error causing PR34596. We do not need to use std::next(BlockIter) when calling updateDepths, as BlockIter already points to the next element. Original commit message: > For large basic blocks with lots of combinable instructions, the > MachineTraceMetrics computations in MachineCombiner can dominate the compile > time, as computing the trace information is quadratic in the number of > instructions in a BB and it's relevant successors/predecessors. > In most cases, knowing the instruction depth should be enough to make > combination decisions. As we already iterate over all instructions in a basic > block, the instruction depth can be computed incrementally. This reduces the > cost of machine-combine drastically in cases where lots of instructions > are combined. The major drawback is that AFAIK, computing the critical path > length cannot be done incrementally. Therefore we only compute > instruction depths incrementally, for basic blocks with more > instructions than inc_threshold. The -machine-combiner-inc-threshold > option can be used to set the threshold and allows for easier > experimenting and checking if using incremental updates for all basic > blocks has any impact on the performance. > > Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn > > Reviewed By: fhahn > > Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits > > Differential Revision: https://reviews.llvm.org/D36619 llvm-svn: 313751
* [MIRPrinter] Print empty successor lists when they cannot be guessedQuentin Colombet2017-09-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-applies commit r313685, this time with the proper updates to the test cases. Original commit message: Unreachable blocks in the machine instr representation are these weird empty blocks with no successors. The MIR printer used to not print empty lists of successors. However, the MIR parser now treats non-printed list of successors as "please guess it for me". As a result, the parser tries to guess the list of successors and given the block is empty, just assumes it falls through the next block (if any). For instance, the following test case used to fail the verifier. The MIR printer would print entry / \ true (def) false (no list of successors) | split.true (use) The MIR parser would understand this: entry / \ true (def) false | / <-- invalid edge split.true (use) Because of the invalid edge, we get the "def does not dominate all uses" error. The fix consists in printing empty successor lists, so that the parser knows what to do for unreachable blocks. rdar://problem/34022159 llvm-svn: 313696
* CodeGen: use range based for loops (NFC)Saleem Abdulrasool2017-09-191-6/+1
| | | | | | | Simplify the RPOT traversal by using a range based for loop for the iterator dereference. llvm-svn: 313687
* Revert "[MIRPrinter] Print empty successor lists when they cannot be guessed"Quentin Colombet2017-09-191-1/+2
| | | | | | | | | This reverts commit r313685. I thought I had ran ninja check, but apparently I didn't... Need to update a bunch of mir tests. llvm-svn: 313686
* [MIRPrinter] Print empty successor lists when they cannot be guessedQuentin Colombet2017-09-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unreachable blocks in the machine instr representation are these weird empty blocks with no successors. The MIR printer used to not print empty lists of successors. However, the MIR parser now treats non-printed list of successors as "please guess it for me". As a result, the parser tries to guess the list of successors and given the block is empty, just assumes it falls through the next block (if any). For instance, the following test case used to fail the verifier. The MIR printer would print entry / \ true (def) false (no list of successors) | split.true (use) The MIR parser would understand this: entry / \ true (def) false | / <-- invalid edge split.true (use) Because of the invalid edge, we get the "def does not dominate all uses" error. The fix consists in printing empty successor lists, so that the parser knows what to do for unreachable blocks. rdar://problem/34022159 llvm-svn: 313685
* Revert "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"Reid Kleckner2017-09-191-54/+35
| | | | | | | | | This reverts r313640, originally r313400, one more time for essentially the same issue. My BitVector of spilled location numbers isn't working because we coalesce identical DBG_VALUE locations as we rewrite them, invalidating the location numbers used to index the BitVector. llvm-svn: 313679
* Re-land "Fix Bug 30978 by emitting cv file checksums."Reid Kleckner2017-09-191-7/+13
| | | | | | | This reverts r313431 and brings back r313374 with a fix to write checksums as binary data and not ASCII hex strings. llvm-svn: 313657
* Re-land r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect ↵Reid Kleckner2017-09-191-35/+54
| | | | | | | | | | | | | | DBG_VALUEs" I forgot to zero out the BitVector when reusing it between UserValues. Later uses of the same location number for a different UserValue would falsely indicate that they were spilled. Usually this would lead to incorrect debug info, but in some cases they would indicate something nonsensical like a memory location based on a vector register (Q8 on ARM). llvm-svn: 313640
* Revert r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect ↵Hans Wennborg2017-09-181-53/+35
| | | | | | | | | | | | | | | | | | | | | | | | | DBG_VALUEs" This caused asserts in Chromium. See http://crbug.com/766261 > Summary: > This comes up in optimized debug info for C++ programs that pass and > return objects indirectly by address. In these programs, > llvm.dbg.declare survives optimization, which causes us to emit indirect > DBG_VALUE instructions. The fast register allocator knows to insert > DW_OP_deref when spilling indirect DBG_VALUE instructions, but the > LiveDebugVariables did not until this change. > > This fixes part of PR34513. I need to look into why this doesn't work at > -O0 and I'll send follow up patches to handle that. > > Reviewers: aprantl, dblaikie, probinson > > Subscribers: qcolombet, hiraditya, llvm-commits > > Differential Revision: https://reviews.llvm.org/D37911 llvm-svn: 313589
* [DAGCombiner] fold assertzexts separated by truncSanjay Patel2017-09-181-2/+25
| | | | | | | | | | | | | If we have an AssertZext of a truncated value that has already been AssertZext'ed, we can assert on the wider source op to improve the zext-y knowledge: assert (trunc (assert X, i8) to iN), i1 --> trunc (assert X, i1) to iN This moves a fold from being Mips-specific to general combining, and x86 shows improvements. Differential Revision: https://reviews.llvm.org/D37017 llvm-svn: 313577
* [DAG, x86] allow store merging before and after legalization (PR34217)Sanjay Patel2017-09-181-4/+4
| | | | | | | | | | | | | | | | | rL310710 allowed store merging to occur after legalization to catch stores that are created late, but this exposes a logic hole seen in PR34217: https://bugs.llvm.org/show_bug.cgi?id=34217 We will miss merging stores if the target lowers vector extracts into target-specific operations. This patch allows store merging to occur both before and after legalization if the target chooses to get maximum merging. I don't think the potential regressions in the other tests are relevant. The tests are for correctness of weird IR constructs rather than perf tests, and I think those are still correct. Differential Revision: https://reviews.llvm.org/D37987 llvm-svn: 313564
* [GlobalISel] Only build expensive remarks if they're enabled. NFC.Ahmed Bougacha2017-09-182-7/+14
| | | | | | | | r313390 taught 'allowExtraAnalysis' to check whether remarks are enabled at all. Use that to only do the expensive instruction printing if they are. llvm-svn: 313552
* [SelectionDAG] Add BITCAST handling to ComputeNumSignBits for splatted sign ↵Simon Pilgrim2017-09-181-0/+24
| | | | | | | | | | | | bits. For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements. We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results. Differential Revision: https://reviews.llvm.org/D37849 llvm-svn: 313543
* Revert "Fix Bug 30978 by emitting cv file checksums."Eric Beckmann2017-09-161-9/+7
| | | | | | | | | | | This reverts commit 6389e7aa724ea7671d096f4770f016c3d86b0d54. There is a bug in this implementation where the string value of the checksum is outputted, instead of the actual hex bytes. Therefore the checksum is incorrect, and this prevent pdbs from being loaded by visual studio. Revert this until the checksum is emitted correctly. llvm-svn: 313431
* Name the sentinel value used for the location number of the undefined ↵Reid Kleckner2017-09-151-7/+9
| | | | | | register NFC llvm-svn: 313405
* [DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEsReid Kleckner2017-09-151-35/+53
| | | | | | | | | | | | | | | | | | | | | Summary: This comes up in optimized debug info for C++ programs that pass and return objects indirectly by address. In these programs, llvm.dbg.declare survives optimization, which causes us to emit indirect DBG_VALUE instructions. The fast register allocator knows to insert DW_OP_deref when spilling indirect DBG_VALUE instructions, but the LiveDebugVariables did not until this change. This fixes part of PR34513. I need to look into why this doesn't work at -O0 and I'll send follow up patches to handle that. Reviewers: aprantl, dblaikie, probinson Subscribers: qcolombet, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D37911 llvm-svn: 313400
* [DebugInfo] Add missing DW_OP_deref when an NRVO pointer is spilledReid Kleckner2017-09-152-62/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR34513. Indirect DBG_VALUEs typically come from dbg.declares of non-trivially copyable C++ objects that must be passed by address. We were already handling the case where the virtual register gets allocated to a physical register and is later spilled. That's what usually happens for normal parameters that aren't NRVO variables: they usually appear in physical register parameters, and are spilled later in the function, which would correctly add deref. NRVO variables are different because the dbg.declare can come much later after earlier instructions cause the incoming virtual register to be spilled. Also, clean up this code. We only need to look at the first operand of a DBG_VALUE, which eliminates the operand loop. Reviewers: aprantl, dblaikie, probinson Subscribers: MatzeB, qcolombet, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37929 llvm-svn: 313399
* [WebAssembly] MC: Create wasm data segments based on MCSectionsSam Clegg2017-09-151-3/+5
| | | | | | | | | | | This means that we can honor -fdata-sections rather than always creating a segment for each symbol. It also allows for a followup change to add .init_array and friends. Differential Revision: https://reviews.llvm.org/D37876 llvm-svn: 313395
* Change encodeU/SLEB128 to pad to certain number of bytesSam Clegg2017-09-152-8/+20
| | | | | | | | | | | | | | | Previously the 'Padding' argument was the number of padding bytes to add. However most callers that use 'Padding' know how many overall bytes they need to write. With the previous code this would mean encoding the LEB once to find out how many bytes it would occupy and then using this to calulate the 'Padding' value. See: https://reviews.llvm.org/D36595 Differential Revision: https://reviews.llvm.org/D37494 llvm-svn: 313393
* Revert r313343 "[X86] PR32755 : Improvement in CodeGen instruction selection ↵Hans Wennborg2017-09-151-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for LEAs." This caused PR34629: asserts firing when building Chromium. It also broke some buildbots building test-suite as reported on the commit thread. > Summary: > 1/ Operand folding during complex pattern matching for LEAs has been > extended, such that it promotes Scale to accommodate similar operand > appearing in the DAG. > e.g. > T1 = A + B > T2 = T1 + 10 > T3 = T2 + A > For above DAG rooted at T3, X86AddressMode will no look like > Base = B , Index = A , Scale = 2 , Disp = 10 > > 2/ During OptimizeLEAPass down the pipeline factorization is now performed over LEAs > so that if there is an opportunity then complex LEAs (having 3 operands) > could be factored out. > e.g. > leal 1(%rax,%rcx,1), %rdx > leal 1(%rax,%rcx,2), %rcx > will be factored as following > leal 1(%rax,%rcx,1), %rdx > leal (%rdx,%rcx) , %edx > > 3/ Aggressive operand folding for AM based selection for LEAs is sensitive to loops, > thus avoiding creation of any complex LEAs within a loop. > > Reviewers: lsaba, RKSimon, craig.topper, qcolombet > > Reviewed By: lsaba > > Subscribers: spatel, igorb, llvm-commits > > Differential Revision: https://reviews.llvm.org/D35014 llvm-svn: 313376
* Fix Bug 30978 by emitting cv file checksums.Eric Beckmann2017-09-151-7/+9
| | | | | | | | | | | | Summary: The checksums had already been placed in the IR, this patch allows MCCodeView to actually write it out to an MCStreamer. Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37157 llvm-svn: 313374
* Recommit "[RegAlloc] Make sure live-ranges reflect the state of the IR whenJonas Paulsson2017-09-152-2/+8
| | | | | | | | | | | | | removing them" This was temporarily reverted, but now that the fix has been commited (r313197) it should be put back in place. https://bugs.llvm.org/show_bug.cgi?id=34502 This reverts commit 9ef93d9dc4c51568e858cf8203cd2c5ce8dca796. llvm-svn: 313349
* [X86] PR32755 : Improvement in CodeGen instruction selection for LEAs.Jatin Bhateja2017-09-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 1/ Operand folding during complex pattern matching for LEAs has been extended, such that it promotes Scale to accommodate similar operand appearing in the DAG. e.g. T1 = A + B T2 = T1 + 10 T3 = T2 + A For above DAG rooted at T3, X86AddressMode will no look like Base = B , Index = A , Scale = 2 , Disp = 10 2/ During OptimizeLEAPass down the pipeline factorization is now performed over LEAs so that if there is an opportunity then complex LEAs (having 3 operands) could be factored out. e.g. leal 1(%rax,%rcx,1), %rdx leal 1(%rax,%rcx,2), %rcx will be factored as following leal 1(%rax,%rcx,1), %rdx leal (%rdx,%rcx) , %edx 3/ Aggressive operand folding for AM based selection for LEAs is sensitive to loops, thus avoiding creation of any complex LEAs within a loop. Reviewers: lsaba, RKSimon, craig.topper, qcolombet Reviewed By: lsaba Subscribers: spatel, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D35014 llvm-svn: 313343
* [codeview] Use a type index of zero for static method "this" typesReid Kleckner2017-09-151-1/+1
| | | | | | | Otherwise VS won't show anything in the autos or watch window of static methods. llvm-svn: 313329
* Add AddresSpace to PseudoSourceValue.Jan Sjodin2017-09-143-19/+36
| | | | | | Differential Revision: https://reviews.llvm.org/D35089 llvm-svn: 313297
* Remove usages of deprecated std::unary_function and std::binary_function.Benjamin Kramer2017-09-141-1/+1
| | | | | | | | | | These are removed in C++17. We still have some users of unary_function::argument_type, so just spell that typedef out. No functionality change intended. Note that many of the argument types are actually wrong :) llvm-svn: 313287
* TableGen support for parameterized register class informationKrzysztof Parzyszek2017-09-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces TableGen's type inference to operate on parameterized types instead of MVTs, and as a consequence, some interfaces have changed: - Uses of MVTs are replaced by ValueTypeByHwMode. - EEVT::TypeSet is replaced by TypeSetByHwMode. This affects the way that types and type sets are printed, and the tests relying on that have been updated. There are certain users of the inferred types outside of TableGen itself, namely FastISel and GlobalISel. For those users, the way that the types are accessed have changed. For typical scenarios, these replacements can be used: - TreePatternNode::getType(ResNo) -> getSimpleType(ResNo) - TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo) - TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false) For more information, please refer to the review page. Differential Revision: https://reviews.llvm.org/D31951 llvm-svn: 313271
* [IfConversion] More simple, correct dead/kill liveness handlingKrzysztof Parzyszek2017-09-142-57/+65
| | | | | | | | Patch by Jesper Antonsson. Differential Revision: https://reviews.llvm.org/D37611 llvm-svn: 313268
* [DAGCombine] (shl (or x, c1), c2) -> (or (shl x, c2), c1 << c2)Simon Pilgrim2017-09-141-2/+4
| | | | | | | | | | We already have a combine for this pattern when the input to shl is add, so we just need to enable the transformation when the input is or. Original patch by @tstellar Differential Revision: https://reviews.llvm.org/D19325 llvm-svn: 313251
* [SelectionDAG] ComputeNumSignBits - cleanup ROTL/ROTR wrapping to match ↵Simon Pilgrim2017-09-141-3/+3
| | | | | | | | | | DAGCombine etc. Use RotAmt.urem(VTBits) instead of AND(RotAmt, VTBits - 1) TBH I don't expect non-power-of-2 types to be created, but it makes the logic clearer and matches what we do in other rotation combines. llvm-svn: 313245
* [XRay][CodeGen] Use the current function symbol as the associated symbol for ↵Dean Michael Berris2017-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the instrumentation map Summary: XRay had been assuming that the previous section is the "text" section of the function when lowering the instrumentation map. Unfortunately this is not a safe assumption, because we may be coming from lowering debug type information for the function being lowered. This fixes an issue with combining -gsplit-dwarf, -generate-type-units, -debug-compile and -fxray-instrument for sole member functions. When the split dwarf section is stripped, we're left with references from the xray_instr_map to the debug section. The change now uses the function's symbol instead of the previous section's start symbol. We found the bug while attempting to strip the split debug sections off an XRay-instrumented object file, which had a peculiar edge-case for single-function classes where the single function is being lowered. Because XRay had assocaited the instrumentation map for a function to the debug types section instead of the function's section, the objcopy call will fail due to the misplaced reference from the xray_instr_map section. Reviewers: pcc, dblaikie, echristo Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D37791 llvm-svn: 313233
* [codeview] Fold FIXME into comment, there's nothing to do. NFCReid Kleckner2017-09-131-4/+4
| | | | llvm-svn: 313214
* Revert r312719 "[MachineCombiner] Update instruction depths incrementally ↵Hans Wennborg2017-09-132-90/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for large BBs." This caused PR34596. > [MachineCombiner] Update instruction depths incrementally for large BBs. > > Summary: > For large basic blocks with lots of combinable instructions, the > MachineTraceMetrics computations in MachineCombiner can dominate the compile > time, as computing the trace information is quadratic in the number of > instructions in a BB and it's relevant successors/predecessors. > > In most cases, knowing the instruction depth should be enough to make > combination decisions. As we already iterate over all instructions in a basic > block, the instruction depth can be computed incrementally. This reduces the > cost of machine-combine drastically in cases where lots of instructions > are combined. The major drawback is that AFAIK, computing the critical path > length cannot be done incrementally. Therefore we only compute > instruction depths incrementally, for basic blocks with more > instructions than inc_threshold. The -machine-combiner-inc-threshold > option can be used to set the threshold and allows for easier > experimenting and checking if using incremental updates for all basic > blocks has any impact on the performance. > > Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn > > Reviewed By: fhahn > > Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits > > Differential Revision: https://reviews.llvm.org/D36619 llvm-svn: 313213
* Allow target to decide when to cluster loads/stores in mischedStanislav Mekhanoshin2017-09-131-6/+2
| | | | | | | | | | | | | | | | MachineScheduler when clustering loads or stores checks if base pointers point to the same memory. This check is done through comparison of base registers of two memory instructions. This works fine when instructions have separate offset operand. If they require a full calculated pointer such instructions can never be clustered according to such logic. Changed shouldClusterMemOps to accept base registers as well and let it decide what to do about it. Differential Revision: https://reviews.llvm.org/D37698 llvm-svn: 313208
* [codeview] VLAs and unsized arrays should use a size of zeroReid Kleckner2017-09-131-3/+4
| | | | | | | | | | | | | | | | | Previously we used a size of '1' for VLAs because we weren't sure what MSVC did. However, MSVC does support declaring an array without a size, for which it emits an array type with a size of zero. Clang emits the same DI metadata for VLAs and arrays without bound, so we would describe arrays without bound as having one element. This lead to Microsoft debuggers only printing a single element. Emitting a size of zero appears to cause these debuggers to search the symbol information to find a definition of the variable with accurate array bounds. Fixes http://crbug.com/763580 llvm-svn: 313203
* [RegAlloc] Keep a copy of live interval for the spilled vregs in ↵Wei Mi2017-09-131-24/+29
| | | | | | | | | | | | | HoistSpillHelper. This is to fix PR34502. After rL311401, the live range of spilled vreg will be cleared. HoistSpill need to use the live range of the original vreg before splitting to know the moving range of the spills. The patch saves a copy of live interval for the spilled vreg inside of HoistSpillHelper. Differential Revision: https://reviews.llvm.org/D37578 llvm-svn: 313197
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-09-1312-136/+248
| | | | | | other minor fixes (NFC). llvm-svn: 313194
* Mark static member functions as static in CodeViewDebugAdrian McCarthy2017-09-132-11/+14
| | | | | | | | | | | | | | Summary: To improve CodeView quality for static member functions, we need to make the static explicit. In addition to a small change in LLVM's CodeViewDebug to return the appropriate MethodKind, this requires a small change in Clang to note the staticness in the debug info metadata. Subscribers: aprantl, hiraditya Differential Revision: https://reviews.llvm.org/D37715 llvm-svn: 313192
* [MachineScheduler] Put SchedRegion in an anonymous namespace.Mikael Holmen2017-09-131-0/+2
| | | | | | | | | | | | | | | | Summary: It pollutes the global namespace otherwise. Patch by: Bevin Hansson Reviewers: jonpa Reviewed By: jonpa Subscribers: MatzeB, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D37555 llvm-svn: 313148
* Remove -generate-dwarf-pub-sections flag.Peter Collingbourne2017-09-121-14/+1
| | | | | | | | | This flag is unnecessary for testing because we can get the coverage we need by adjusting CU attributes. Differential Revision: https://reviews.llvm.org/D37725 llvm-svn: 313079
* IR: Represent -ggnu-pubnames with a flag on the DICompileUnit.Peter Collingbourne2017-09-124-120/+93
| | | | | | | | This allows the flag to be persisted through to LTO. Differential Revision: https://reviews.llvm.org/D37655 llvm-svn: 313078
* Update branch coalescing to be a PowerPC specific passLei Huang2017-09-124-763/+0
| | | | | | | | | | | | Implementing this pass as a PowerPC specific pass. Branch coalescing utilizes the analyzeBranch method which currently does not include any implicit operands. This is not an issue on PPC but must be handled on other targets. Pass is currently off by default. Enabled via -enable-ppc-branch-coalesce. Differential Revision : https: // reviews.llvm.org/D32776 llvm-svn: 313061
* [WebAssembly] Remove flags from MCSectionWasmSam Clegg2017-09-121-9/+5
| | | | | | | | | | | Looks like these were copied from the ELF sections but don't apply to Wasm and were not used anywhere. Also remove unused Wasm methods in MCContext. Differential Revision: https://reviews.llvm.org/D37633 llvm-svn: 313058
* Revert "[DWARF] Incorrect prologue end line record."Robert Lougher2017-09-121-3/+1
| | | | | | | This reverts commit r313047 as it is causing buildbot failure (lldb inline stepping tests). llvm-svn: 313057
* [DWARF] Incorrect prologue end line record.Robert Lougher2017-09-121-1/+3
| | | | | | | | | | | | A prologue-end line record is emitted with an incorrect associated address, which causes a debugger to show the beginning of function body to be inside the prologue. Patch written by Carlos Alberto Enciso. Differential Revision: https://reviews.llvm.org/D37625 llvm-svn: 313047
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-09-118-146/+225
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 312971
* Unmerge GEPs to reduce register pressure on IndirectBr edges.Hiroshi Yamauchi2017-09-111-0/+167
| | | | | | | | | | | | | | | | | | | | | | | Summary: GEP merging can sometimes increase the number of live values and register pressure across control edges and cause performance problems particularly if the increased register pressure results in spills. This change implements GEP unmerging around an IndirectBr in certain cases to mitigate the issue. This is in the CodeGenPrepare pass (after all the GEP merging has happened.) With this patch, the Python interpreter loop runs faster by ~5%. Reviewers: sanjoy, hfinkel Reviewed By: hfinkel Subscribers: eastig, junbuml, llvm-commits Differential Revision: https://reviews.llvm.org/D36772 llvm-svn: 312930
OpenPOWER on IntegriCloud