summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [XRay][CodeGen][PowerPC] Fix tail exit codegen for XRay in PPCDean Michael Berris2017-09-081-16/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes code-gen for XRay in PPC. The regression wasn't caught by codegen tests which we add in this change. What happened was the following: - For tail exits, we used to unconditionally prepend the returns/exits with a pseudo-instruction that gets lowered to the instrumentation sled (and leave the actual return/exit instruction as-is). - Changes to the XRay instrumentation pass caused the tail exits to suddenly also emit the tail exit pseudo-instruction, since the check for whether a return instruction was also a call instruction meant it was a tail exit instruction. - None of the tests caught the regression either due to non-existent tests, or the tests being disabled/removed for continuous breakage. This change re-introduces some of the basic tests and verifies that we're back to a state that allows the back-end to generate appropriate XRay instrumented binaries for PPC in the presence of tail exits. Reviewers: echristo, timshen Subscribers: nemanjai, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D37570 llvm-svn: 312772
* Sink some IntrinsicInst.h and Intrinsics.h out of llvm/includeReid Kleckner2017-09-071-0/+1
| | | | | | | Many of these uses can get by with forward declarations. Hopefully this speeds up compilation after adding a single intrinsic. llvm-svn: 312759
* Revert r312318, r312325, r312424, r312489Richard Trieu2017-09-071-1/+0
| | | | | | | | | | r312318 - Debug info for variables whose type is shrinked to bool r312325, r312424, r312489 - Test case for r312318 Revision 312318 introduced a null dereference bug. Details in https://bugs.llvm.org/show_bug.cgi?id=34490 llvm-svn: 312758
* [DWARF] Line 0 should not have a discriminator.Paul Robinson2017-09-071-2/+2
| | | | | | | | It's meaningless and takes up extra space in the line table. Differential Revision: https://reviews.llvm.org/D37364 llvm-svn: 312751
* DAG: Allow creating extract_vector_elt post-legalizeMatt Arsenault2017-09-071-1/+4
| | | | | | | | | | | | | | | | Fixes some combine issues for AMDGPU where we weren't getting the many extract_vector_elt combines expected in a future patch. This should really be checking isOperationLegalOrCustom on the extract. That improves a number of x86 lit tests, but a few get stuck in an infinite loop from one place where a similar looking extract is created. I have a different workaround in the backend for that which keeps many of those improvements, but also adds a few regressions. llvm-svn: 312730
* [MachineCombiner] Update instruction depths incrementally for large BBs.Florian Hahn2017-09-072-23/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 312719
* [MachineTraceMetrics] Add computeDepth function (NFCI).Florian Hahn2017-09-071-54/+46
| | | | | | | | | | | | | | | | Summary: This function is used in D36619 to update the instruction depths incrementally. Reviewers: efriedma, Gerolf, MatzeB, fhahn Reviewed By: fhahn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36696 llvm-svn: 312714
OpenPOWER on IntegriCloud