summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [SelectionDAG] Remove a check for type being a vector type after calling ↵Craig Topper2017-09-111-2/+0
| | | | | | | | getShiftAmountTy. NFCI getShiftAmountTy already returns the vector type when called for vectors. llvm-svn: 312924
* Fix typoMatt Arsenault2017-09-111-1/+1
| | | | llvm-svn: 312919
* Fixed a bug in splitting Scatter operation in the Type Legalizer.Elena Demikhovsky2017-09-111-7/+6
| | | | | | | | | After the split of the Scatter operation, the order of the new instructions is well defined - Lo goes before Hi. Otherwise the semantic of Scatter (from LSB to MSB) is broken. I'm chaining 2 nodes to prevent reordering. Differential Revision https://reviews.llvm.org/D37670 llvm-svn: 312894
* RegAllocFast: Fix warning; NFCMatthias Braun2017-09-091-2/+1
| | | | llvm-svn: 312852
* RegAllocFast: Cleanup; NFCMatthias Braun2017-09-092-300/+297
| | | | | | | | | | | | | - Use range based for - Variable names should start with upper case - Add `const` - Change class name to match filename - Fix doxygen comments - Use MCPhysReg instead of unsigned - Use references instead of pointers where things cannot be nullptr - Misc coding style improvements llvm-svn: 312846
* RegAllocFast: Move vector to class level to avoid reallocation; NFCMatthias Braun2017-09-091-2/+5
| | | | llvm-svn: 312845
* RegAllocFast: Remove write-only set; NFCMatthias Braun2017-09-091-10/+0
| | | | llvm-svn: 312844
* Fix a bug for rL312641.Wei Mi2017-09-081-4/+11
| | | | | | | | | | | rL312641 Allowed llvm.memcpy/memset/memmove to be tail calls when parent function return the intrinsics's first argument. However on arm-none-eabi platform, llvm.memcpy will be expanded to __aeabi_memcpy which doesn't have return value. The fix is to check the libcall name after expansion to match "memcpy/memset/memmove" before allowing those intrinsic to be tail calls. llvm-svn: 312799
* Preserve existing regs when adding pristines to LivePhysRegs/LiveRegUnitsKrzysztof Parzyszek2017-09-082-14/+43
| | | | | | Differential Revision: https://reviews.llvm.org/D37600 llvm-svn: 312797
* Fix a crash when emitting debug info for multi-reg function argumentsAdrian Prantl2017-09-081-14/+18
| | | | | | | | | by reusing more of the existing machinery This is a follow-up to r312169. Thanks to Björn Pettersson for the testcase! llvm-svn: 312773
OpenPOWER on IntegriCloud