summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* DebugInfo: Fix LTO+DWARFv5 loclistsDavid Blaikie2019-12-051-1/+1
| | | | | | The loclists_table_base was being overwritten for each CU even though only one loclists contribution is made so everything but the last CU would have a label that was never defined and fail to assemble.
* [GlobalISel] Localizer: Allow targets not to run the pass conditionallyVolkan Keles2019-12-051-1/+9
| | | | | | | | | | | | | | | | | | | Summary: Previously, it was not possible to skip running the localizer pass conditionally. This patch adds an input function to the pass which decides if the pass should run on the given MachineFunction or not. No test case as there is no upstream target needs this functionality. Reviewers: qcolombet Reviewed By: qcolombet Subscribers: rovka, hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71038
* [DebugInfo] Don't create multiple DBG_VALUEs when sinkingJeremy Morse2019-12-051-10/+74
| | | | | | | | | | | | | | | | | This patch addresses a performance problem reported in PR43855, and present in the reapplication in in 001574938e5. It turns out that MachineSink will (often) move instructions to the first block that post-dominates the current block, and then try to sink further. This means if we have a lot of conditionals, we can needlessly create large numbers of DBG_VALUEs, one in each block the sunk instruction passes through. To fix this, rather than immediately sinking DBG_VALUEs, record them in a pass structure. When sinking is complete and instructions won't be sunk any further, new DBG_VALUEs are added, avoiding lots of intermediate DBG_VALUE $noregs being created. Differential revision: https://reviews.llvm.org/D70676
* [DebugInfo] Don't reorder DBG_VALUEs when sunkJeremy Morse2019-12-051-51/+93
| | | | | | | | | | | | | | | | | | | | | | | Fix part of PR43855, resolving a problem that comes from the reapplication in 001574938e5. If we have two DBG_VALUE insts in a block that specify the location of the same variable, for example: %0 = someinst DBG_VALUE %0, !123, !DIExpression() %1 = anotherinst DBG_VALUE %1, !123, !DIExpression() if %0 were to sink, the corresponding DBG_VALUE would sink too, past the next DBG_VALUE, effectively re-ordering assignments. To fix this, I've added a SeenDbgVars set recording what variable locations have been seen in a block already (working bottom up), and now flag DBG_VALUEs that would pass a later DBG_VALUE for the same variable. NB, this only works for repeated DBG_VALUEs in the same basic block, the general case involving control flow is much harder, which I've written up in PR44117. Differential revision: https://reviews.llvm.org/D70672
* [DebugInfo] Re-apply two patches to MachineSinkJeremy Morse2019-12-051-17/+138
| | | | | | | | | | | | | These were: * D58386 / f5e1b718a67 / reverted in d382a8a768b * D58238 / ee50590e168 / reverted in a8db456b53a Of which the latter has a performance regression tracked in PR43855, fixed by D70672 / D70676, which will be committed atomically with this reapplication. Contains a minor difference to account for a change in the IsCopyInstr signature.
* [ARM] Enable TypePromotion by defaultSam Parker2019-12-051-3/+21
| | | | | | | | ARMCodeGenPrepare has already been generalized and renamed to TypePromotion. We've had it enabled and tested downstream for a while, so enable it by default. Differential Revision: https://reviews.llvm.org/D70998
* [LiveDebugValues] Silence the unused var warning; NFCDjordje Todorovic2019-12-051-2/+1
|
* [DebugInfo] Handle call site values for instructions before call bundleDavid Stenberg2019-12-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: If a call is bundled then the code that looks for instructions that produce parameter values would break when reaching the call's bundle header, due to the `ifCall(/*AnyInBundle*/)` invocation returning true. It is not enough to simply ignore bundle headers in the `isCall()` invocation, as the bundle header may have defines of parameter registers due to the call, meaning that such registers would incorrectly be removed from the worklist. Therefore, do not look at bundle headers at all. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: aprantl, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D71024
* Reland "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-051-81/+304
| | | | Relanding this after resolving the cause of the test failure.
* [MCRegInfo] Add forward sub and super register iterators. (NFC)Florian Hahn2019-12-052-16/+13
| | | | | | | | | | | | | | | | | | | This patch adds forward iterators mc_difflist_iterator, mc_subreg_iterator and mc_superreg_iterator, based on the existing DiffListIterator. Those are used to provide iterator ranges over sub- and super-register from TRI, which are slightly more convenient than the existing MCSubRegIterator/MCSuperRegIterator. Unfortunately, it duplicates a bit of functionality, but the new iterators are a bit more convenient (and can be used with various existing iterator utilities) and should probably replace the old iterators in the future. This patch updates some existing users. Reviewers: evandro, qcolombet, paquette, MatzeB, arsenm Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D70565
* [MIBundle] Turn MachineOperandIteratorBase into a forward iterator.Florian Hahn2019-12-051-3/+3
| | | | | | | | | | | | | | | This patch turns MachineOperandIteratorBase into a regular forward iterator, which can be used with iterator_range. It also adds mi_bundle_ops and const_mi_bundle_ops that return iterator ranges over all operands in a bundle and updates a use of the old iterator. Reviewers: evandro, t.p.northover, paquette, MatzeB, arsenm Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D70561
* Reland [MachineCopyPropagation] Extend MCP to do trivial copy backward ↵Kai Luo2019-12-051-5/+217
| | | | | | | | | | propagation. Fix assertion error ``` bool llvm::MachineOperand::isRenamable() const: Assertion `Register::isPhysicalRegister(getReg()) && "isRenamable should only be checked on physical registers"' failed. ``` by checking if the register is 0 before invoking `isRenamable`.
* Revert "[MachineCopyPropagation] Extend MCP to do trivial copy backward ↵Kai Luo2019-12-051-211/+5
| | | | | | | propagation" This reverts commit 75b3a1c318ccad0f96c38689279bc5db63e2ad05, since it breaks bootstrap build.
* [MachineCopyPropagation] Extend MCP to do trivial copy backward propagationKai Luo2019-12-051-5/+211
| | | | | | | | | | | | | | | | | | Summary: This patch mainly do such transformation ``` $R0 = OP ... ... // No read/clobber of $R0 and $R1 $R1 = COPY $R0 // $R0 is killed ``` Replace $R0 with $R1 and remove the COPY, we have ``` $R1 = OP ... ``` This transformation can also expose more opportunities for existing copy elimination in MCP. Differential Revision: https://reviews.llvm.org/D67794
* [GlobalISel] Fix compiler crash lowering G_LOAD in AArch64.Amara Emerson2019-12-041-1/+1
| | | | | | Patch by Daniel Rodríguez Troitiño. Differential Revision: https://reviews.llvm.org/D70794
* [llvm] Fixing MIRVRegNamerUtils to properly handle 2+ MachineBasicBlocks.Puyan Lotfi2019-12-043-31/+8
| | | | | | | | | | | An interplay of code from D70210, along with code from the Value-Numbering-esque hash-based namer from D70210, as well as some crusty code from the original MIR-Canon code lead to multiple causes of failure when canonicalizing or renaming vregs for MIR with multiple basic blocks. This patch fixes those issues while deleting some no longer needed code and adding a nice diamond test case to boot. Differential Revision: https://reviews.llvm.org/D70478
* [DWARF5][Debuginfo] Compilation unit type (DW_UT_skeleton) and root DIE ↵Alexey Lapshin2019-12-054-5/+24
| | | | | | | | | | | | | | | | | | | | (DW_TAG_compile_unit) do not match. That patch fixes incompatible compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) error. cat split-dwarf.cpp int main() { int a = 1; return 0; } clang++ -O -g -gsplit-dwarf -gdwarf-5 split-dwarf.cpp; llvm-dwarfdump --verify ./a.out | grep skeleton error: Compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) do not match. The fix is to change DW_TAG_compile_unit into DW_TAG_skeleton_unit when skeleton file is generated. Differential Revision: https://reviews.llvm.org/D70880
* Add support for lowering 32-bit/64-bit pointersAmy Huang2019-12-041-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This follows a previous patch that changes the X86 datalayout to represent mixed size pointers (32-bit sext, 32-bit zext, and 64-bit) with address spaces (https://reviews.llvm.org/D64931) This patch implements the address space cast lowering to the corresponding sign extension, zero extension, or truncate instructions. Related to https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, craig.topper, RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69639
* Revert "[Coverage] Revise format to reduce binary size"Vedant Kumar2019-12-041-2/+0
| | | | | | | | | | This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc. On Windows, there is an error: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data
* [Coverage] Revise format to reduce binary sizeVedant Kumar2019-12-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
* [NFC] Use default case in EVT::getEVTStringCullen Rhodes2019-12-041-127/+2
| | | | | | | | | | Summary: The default case handles the majority of MVTs so most of the individual cases can be removed. Also added a case for floating point types. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D70955
* [SelectionDAG] Expand nnan FMINNUM/FMAXNUM to select sequenceUlrich Weigand2019-12-041-0/+20
| | | | | | | | | | | | | | | | | InstCombine may synthesize FMINNUM/FMAXNUM nodes from fcmp+select sequences (where the fcmp is marked nnan). Currently, if the target does not otherwise handle these nodes, they'll get expanded to libcalls to fmin/fmax. However, these functions may reside in libm, which may introduce a library dependency that was not originally present in the source code, potentially resulting in link failures. To fix this problem, add code to TargetLowering::expandFMINNUM_FMAXNUM to expand FMINNUM/FMAXNUM to a compare+select sequence instead of the libcall. This is done only if the node is marked as "nnan"; in this case, the expansion to compare+select is always correct. This also suffices to catch all cases where FMINNUM/FMAXNUM was synthesized as above. Differential Revision: https://reviews.llvm.org/D70965
* [MacroFusion] Limit the max fused number as 2 to reduce the dependencyQingShan Zhang2019-12-041-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the example: int foo(int a, int b, int c, int d) { return a + b + c + d; } And this is the Dependency Graph: +------+ +------+ +------+ +------+ | A | | B | | C | | D | +--+--++ +---+--+ +--+---+ +--+---+ ^ ^ ^ ^ ^ ^ | | | | | | | | | |New1 +--------------+ | | | | | | | | | +--+---+ | |New2 | +-------+ ADD1 | | | | +--+---+ | | | Fuse ^ | | +-------------+ | +------------+ | | | Fuse +--+---+ +----------->+ ADD2 | | +------+ +--+---+ | ADD3 | +------+ We need also create an artificial edge from ADD1 to A if https://reviews.llvm.org/D69998 is landed. That will force the Node A scheduled before the ADD1 and ADD2. But in fact, it is ok to schedule the Node A in-between ADD3 and ADD2, as ADD3 and ADD2 are NOT a fusion pair because ADD2 has been matched to ADD1. We are creating these unnecessary dependency edges that override the heuristics. Differential Revision: https://reviews.llvm.org/D70066
* [FPEnv] [PowerPC] Lowering ppc_fp128 StrictFP Nodes to libcallsCraig Topper2019-12-034-210/+283
| | | | | | | | This is an alternative to D64662 that shares more code between strict and non-strict nodes. It's modeled after the implementation that I did for softening. Differential Revision: https://reviews.llvm.org/D70867
* [GlobalISel]: Allow targets to override how to widen constants during ↵Aditya Nandakumar2019-12-032-1/+13
| | | | | | | | | | | | | | | legalization https://reviews.llvm.org/D70922 This adds a hook to allow targets to define exactly what extension operation should be performed for widening constants. This handles cases like widening i1 true which would end up becoming -1 which affects code quality during combines. Additionally, in order to stay consistent with how DAG is promoting constants, we now signextend for byte sized types and zero extend otherwise (by default). Targets can of course override this if necessary.
* [NFC][KnownBits] Add getMinValue() / getMaxValue() methodsRoman Lebedev2019-12-031-3/+3
| | | | | | | | | | As it can be seen from accompanying cleanup, it is not unheard of to write `~Known.Zero` meaning "what maximal value can this KnownBits produce". But i think `~Known.Zero` isn't *that* self-explanatory, as compared to a method with a name. Note that not all `~Known.Zero` places were cleaned up, only those where this arguably improves things.
* [SelectionDAG] Reoder ViewXXXDAGs declarations to match execution order. NFCAmaury Séchet2019-12-031-14/+12
|
* [DebugInfo] Make DebugVariable class available in DebugInfoMetadatastozer2019-12-031-111/+26
| | | | | | | | The DebugVariable class is a class declared in LiveDebugValues.cpp which is used to uniquely identify a single variable, using its source variable, inline location, and fragment info to do so. This patch moves this class into DebugInfoMetadata.h, making it available in a much broader scope.
* [NFCI][DebugInfo] Corrected a comment.Sourabh Singh Tomar2019-12-031-2/+2
|
* Revert "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-031-301/+78
| | | | This reverts commit rG4cfceb910692 due to LLDB test failing.
* [CodeGen] Move ARMCodegenPrepare to TypePromotionSam Parker2019-12-033-0/+1000
| | | | | | | | | | | | | | | | | | Convert ARMCodeGenPrepare into a generic type promotion pass by: - Removing the insertion of arm specific intrinsics to handle narrow types as we weren't using this. - Removing ARMSubtarget references. - Now query a generic TLI object to know which types should be promoted and what they should be promoted to. - Move all codegen tests into Transforms folder and testing using opt and not llc, which is how they should have been written in the first place... The pass searches up from icmp operands in an attempt to safely promote types so we can avoid generating unnecessary unsigned extends during DAG ISel. Differential Revision: https://reviews.llvm.org/D69556
* ImplicitNullChecks: Don't add a dead definition of DepMI as live-inJonas Paulsson2019-12-031-1/+1
| | | | | | | | This is one of the fixes needed to reapply D68267 which improves verification of live-in lists. Review: craig.topper https://reviews.llvm.org/D70434
* [LiveDebugValues] Introduce entry values of unmodified paramsDjordje Todorovic2019-12-031-78/+301
| | | | | | | | | | | | | | | | | | | | | The idea is to remove front-end analysis for the parameter's value modification and leave it to the value tracking system. Front-end in some cases marks a parameter as modified even the line of code that modifies the parameter gets optimized, that implies that this will cover more entry values even. In addition, extending the support for modified parameters will be easier with this approach. Since the goal is to recognize if a parameter’s value has changed, the idea at very high level is: If we encounter a DBG_VALUE other than the entry value one describing the same variable (parameter), we can assume that the variable’s value has changed and we should not track its entry value any more. That would be ideal scenario, but due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value. Differential Revision: https://reviews.llvm.org/D68209
* [MachineVerifier] Improve checks of target instructions operands.Jonas Paulsson2019-12-031-7/+17
| | | | | | | | | | | | | | | | While working with a patch for instruction selection, the splitting of a large immediate ended up begin treated incorrectly by the backend. Where a register operand should have been created, it instead became an immediate. To my surprise the machine verifier failed to report this, which at the time would have been helpful. This patch improves the verifier so that it will report this type of error. This patch XFAILs CodeGen/SPARC/fp128.ll, which has been reported at https://bugs.llvm.org/show_bug.cgi?id=44091 Review: thegameg, arsenm, fhahn https://reviews.llvm.org/D63973
* [LegalizeDAG] Return true from ExpandNode for some nodes that don't have ↵Craig Topper2019-12-021-1/+3
| | | | | | | | | | | | | | expand support. These nodes have a FIXME that they only get here because a Custom handler returned SDValue() instead of the original Op. Even though we aren't expanding them, we should return true here to prevent ConvertNodeToLibcall from also trying to process them until the FIXME has been addressed. I'm hoping to add checking to ConvertNodeToLibcall to make sure we don't give it nodes it doesn't have support for.
* [LegalizeDAG] When expanding vector SRA/SRL/SHL add the new BUILD_VECTOR to ↵Craig Topper2019-12-021-1/+1
| | | | | | | | | | | | | | | | the Results vector instead of just calling ReplaceNode The code that processes the Results vector also calls ReplaceNode and makes ExpandNode return true. If we don't add it to the Results node, we end up returning false from ExpandNode. This causes ConvertNodeToLibcall to be called next. But ConvertNodeToLibcall doesn't do anything for shifts so they just pass through unmodified. Except for printing a debug message. Ultimately, I'd like to add more checks to ExpandNode and ConvertNodeToLibcall to make sure we don't have nodes marked as Expand that don't have any Expand or libcall handling.
* Recommit "[DWARF5]Addition of alignment atrribute in typedef DIE."Sourabh Singh Tomar2019-12-031-0/+9
| | | | | | | | | | | | | | | | This revision is revised to update Go-bindings and Release Notes. The original commit message follows. This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* [DebugInfo] Support for debug_macinfo.dwo section in llvm and llvm-dwarfdump.Sourabh Singh Tomar2019-12-032-2/+26
| | | | | | | | | | | This patch adds support for debug_macinfo.dwo section[pre-standardized] to llvm and llvm-dwarfdump. Reviewers: probinson, dblaikie, aprantl, jini.susan.george, alok Differential Revision: https://reviews.llvm.org/D70705 Tags: #debug-info #llvm
* [PGO][PGSO] Add an optional query type parameter to shouldOptimizeForSize.Hiroshi Yamauchi2019-12-021-4/+6
| | | | | | | | | | | | | | Summary: In case of a need to distinguish different query sites for gradual commit or debugging of PGSO. NFC. Reviewers: davidxl Subscribers: hiraditya, zzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70510
* [MIBundles] Move analyzePhysReg out of MIBundleOperands iterator (NFC).Florian Hahn2019-12-023-15/+7
| | | | | | | | | | | analyzePhysReg does not really fit into the iterator and moving it makes it easier to change the base iterator. Reviewers: evandro, t.p.northover, paquette, MatzeB, arsenm, qcolombet Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D70559
* [GlobalISel] CombinerHelper: Fix a bug in matchCombineCopyVolkan Keles2019-12-021-3/+26
| | | | | | | | | | | | | | | | | Summary: When combining COPY instructions, we were replacing the destination registers with the source register without checking register constraints. This patch adds a simple logic to check if the constraints match before replacing registers. Reviewers: qcolombet, aditya_nandakumar, aemerson, paquette, dsanders, Petar.Avramovic Reviewed By: aditya_nandakumar Subscribers: rovka, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70616
* [MIBundles] Move analyzeVirtReg out of MIBundleOperands iterator (NFC).Florian Hahn2019-12-022-17/+16
| | | | | | | | | | | analyzeVirtReg does not really fit into the iterator and moving it makes it easier to change the base iterator. Reviewers: evandro, t.p.northover, paquette, MatzeB, arsenm, qcolombet Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D70558
* [DAGCombine] Factor oplist operations. NFCAmaury Séchet2019-12-021-6/+10
|
* [SelectionDAG] Reduce assumptions made about levels. NFCAmaury Séchet2019-12-021-7/+8
|
* Fix a typo.Hans Wennborg2019-11-301-1/+1
|
* [LegalizeTypes] Add strict FP support to SoftenFloatRes_FP_ROUND. Fix ↵Craig Topper2019-11-281-6/+13
| | | | | | | | | | | mistake in SoftenFloatRes_FP_EXTEND. These will be needed for ARM fp-instrinsics.ll which is currently XFAILed. One of the getOperand calls in SoftenFloatRes_FP_EXTEND was not taking strict FP into account. It only affected the call to setTypeListBeforeSoften which only has an effect on some targets.
* [LegalizeTypes] In SoftenFloatRes_FNEG, always generate integer arithmetic, ↵Craig Topper2019-11-281-19/+4
| | | | | | | | never fall back to using fsub. We would previously fallback if the type wasn't f32/f64/f128. But I don't think any of the other floating point types ever go through the softening code anyway. So this code is dead.
* [LegalizeTypes] Use SoftenFloatRes_Unary in SoftenFloatRes_FCBRT to reduce code.Craig Topper2019-11-281-8/+2
| | | | | We don't have a STRICT_CBRT ISD opcode, but we can still use SoftenFloatRes_Unary to simplify some code.
* [DAGCombiner] Peek through vector concats when trying to combine shuffles.Amaury Séchet2019-11-281-9/+42
| | | | | | | | | | | | Summary: This combine showed up as needed when exploring the regression when processing the DAG in topological order. Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68195
* [LegalizeTypes] Remove dead code related to softening f16 which we no longer do.Craig Topper2019-11-272-27/+0
| | | | | | | f16 is promoted to f32 if it is not legal on the target. Found while reviewing what else needed to be done for strict FP in the softening code.
OpenPOWER on IntegriCloud