summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [GlobalISel] Remove non-determinism from IRTranslator.Kristof Beyls2017-04-191-12/+16
| | | | | | | | | | | This showed up in r300535/r300537, which were reverted in r300538 due to some of the introduced tests in there failing on some bots, due to the non-determinism fixed in this commit. Re-committing r300535/r300537 will add 2 tests for the change in this commit. llvm-svn: 300663
* [X86] Keep EXTRACT_VECTOR_ELT result type as f128 for Android x86_64.Chih-Hung Hsieh2017-04-182-3/+6
| | | | | | | | | | Android x86_64 target uses f128 type and stores f128 values in %xmm* registers. SoftenFloatRes_EXTRACT_VECTOR_ELT should not convert result value from f128 to i128. Differential Revision: http://reviews.llvm.org/D32102 llvm-svn: 300583
* [APInt] Use lshrInPlace to replace lshr where possibleCraig Topper2017-04-185-21/+20
| | | | | | | | | | This patch uses lshrInPlace to replace code where the object that lshr is called on is being overwritten with the result. This adds an lshrInPlace(const APInt &) version as well. Differential Revision: https://reviews.llvm.org/D32155 llvm-svn: 300566
* [DAG] Improve store merge candidate pruning.Nirav Dave2017-04-181-0/+21
| | | | | | | | | | | | | | Remove non-consecutive stores from store merge candidate search as they cannot be merged and will prevent us from finding subsequent mergeable store cases. Reviewers: jyknight, bogner, javed.absar, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32086 llvm-svn: 300561
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-182-6/+5
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-182-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-1813-124/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* [CodeGenPrepare] Fix crash due to an invalid CFGBrendon Cahoon2017-04-171-2/+8
| | | | | | | | | | | | | | | The splitIndirectCriticalEdges function generates and invalid CFG when the 'Target' basic block is a loop to itself. When this occurs, the code that updates the predecessor terminator needs to update the terminator in the split basic block. This occurs when there is an edge from block D back to D. Since D is split in to D0 and D1, the code needs to update the terminator in D1. But D1 is not in the OtherPreds vector, so it was not getting updated. Differential Revision: https://reviews.llvm.org/D32126 llvm-svn: 300480
* Distinguish between code pointer size and DataLayout::getPointerSize() in ↵Konstantin Zhuravlyov2017-04-175-17/+19
| | | | | | DWARF info generation llvm-svn: 300463
* [ProfileData] Unify getInstrProf*SectionName helpersVedant Kumar2017-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | This is a version of D32090 that unifies all of the `getInstrProf*SectionName` helper functions. (Note: the build failures which D32090 would have addressed were fixed with r300352.) We should unify these helper functions because they are hard to use in their current form. E.g we recently introduced more helpers to fix section naming for COFF files. This scheme doesn't totally succeed at hiding low-level details about section naming, so we should switch to an API that is easier to maintain. This is not an NFC commit because it fixes llvm-cov's testing support for COFF files (this falls out of the API change naturally). This is an area where we lack tests -- I will see about adding one as a follow up. Testing: check-clang, check-profile, check-llvm. Differential Revision: https://reviews.llvm.org/D32097 llvm-svn: 300381
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-143-22/+20
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* [Profile] Make host tool aware of object format when quering prof section names Xinliang David Li2017-04-141-4/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D32073 llvm-svn: 300352
* Reorder StoreMergeCandidates to run faster. NFCI.Nirav Dave2017-04-141-20/+23
| | | | llvm-svn: 300321
* Fix for PR#30562: Selection DAG error: Detected cycle in SelectionDAG.Andrew V. Tischenko2017-04-141-2/+5
| | | | | | Patch by Dinar Temirbulatov llvm-svn: 300314
* This patch closes PR#32216: Better testing of schedule model instruction ↵Andrew V. Tischenko2017-04-143-11/+152
| | | | | | | | latencies/throughputs. The details are here: https://reviews.llvm.org/D30941 llvm-svn: 300311
* LLVMCodeGen: Add ProfileData into deps corresponding to r300277.NAKAMURA Takumi2017-04-141-1/+1
| | | | llvm-svn: 300289
* [Profile] PE binary coverage bug fixXinliang David Li2017-04-131-1/+3
| | | | | | | | PR/32584 Differential Revision: https://reviews.llvm.org/D32023 llvm-svn: 300277
* [DAG] Fold away temporary vector in store candidate merge NFC.Nirav Dave2017-04-131-14/+11
| | | | llvm-svn: 300241
* Use methods to access data stored with frame instructionsSerge Pavlov2017-04-133-26/+8
| | | | | | | | | | | | | Instructions CALLSEQ_START..CALLSEQ_END and their target dependent counterparts keep data like frame size, stack adjustment etc. These data are accessed by getOperand using hard coded indices. It is error prone way. This change implements the access by special methods, which improve readability and allow changing data representation without massive changes of index values. Differential Revision: https://reviews.llvm.org/D31953 llvm-svn: 300196
* [SelectionDAG] Use APInt move assignment to avoid 2 memory allocations and ↵Craig Topper2017-04-121-2/+2
| | | | | | copies when bit width is larger than 64-bits. llvm-svn: 300091
* CodeGen: BlockPlacement: Add comment about DenseMap Safety.Kyle Butt2017-04-121-0/+3
| | | | | | | | | The use of a DenseMap in precomputeTriangleChains does not cause non-determinism, even though it is iterated over, as the only thing the iteration does is to insert entries into a new DenseMap, which is not iterated. Comment only change. llvm-svn: 300088
* MachineScheduler: Skip acyclic latency heuristic for in-order coresMatthias Braun2017-04-121-1/+1
| | | | | | | | | | | | | | | | | The current heuristic is triggered on `InFlightCount > BufferLimit` which isn't really helpful on in-order cores where BufferLimit is zero. Note that we already get latency hiding effects for in order cores by instructions staying in the pending queue on stalls; The additional latency scheduling heuristics only have minimal effects after that while occasionally increasing register pressure too much resulting in extra spills. My motivation here is additional spills/reloads ending up in a loop in 464.h264ref / BlockMotionSearch function resulting in a 4% overal regression on an in order core. rdar://30264380 llvm-svn: 300083
* Remove redundant type castsSerge Pavlov2017-04-121-12/+8
| | | | llvm-svn: 300063
* [MachineBlockPlacment] Add an assert to ensure there is no order dependency ↵Benjamin Kramer2017-04-121-3/+7
| | | | | | on DenseMap iteration order. llvm-svn: 300060
* [MachineBlockPlacement] Clean up data structures a bit.Benjamin Kramer2017-04-121-21/+17
| | | | | | No functionality change intended. llvm-svn: 300059
* [IR] Redesign the case iterator in SwitchInst to actually be an iteratorChandler Carruth2017-04-121-1/+1
| | | | | | | | | | | | | | | | and to expose a handle to represent the actual case rather than having the iterator return a reference to itself. All of this allows the iterator to be used with common STL facilities, standard algorithms, etc. Doing this exposed some missing facilities in the iterator facade that I've fixed and required some work to the actual iterator to fully support the necessary API. Differential Revision: https://reviews.llvm.org/D31548 llvm-svn: 300032
* [INC] Test commit. NFC.Serguei Katkov2017-04-121-1/+1
| | | | | | Just an update of comment. llvm-svn: 300026
* CodeGen: BlockPlacement: Clear ComputedEdges between functions.Kyle Butt2017-04-121-2/+5
| | | | | | | | Not clearing was causing non-deterministic compiles for large files. Addresses for MachineBasicBlocks would end up colliding and we would lay out a block that we assumed had been pre-computed when it had not been. llvm-svn: 300022
* MIR: Allow parsing of empty machine functionsJustin Bogner2017-04-112-5/+4
| | | | | | | | | | | | If you run llc -stop-after=codegenprepare and feed the resulting MIR to llc -start-after=codegenprepare, you'll have an empty machine function since we haven't run any isel yet. Of course, this only works if the MIRParser believes you that this is okay. This is essentially a revert of r241862 with a fix for the problem it was papering over. llvm-svn: 299975
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-117-12/+12
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* [SDAG] Factor CandidateMatch check into lambda. NFC.Nirav Dave2017-04-111-28/+29
| | | | llvm-svn: 299939
* [SDAG] Factor ChainMerge into helper function NFCI.Nirav Dave2017-04-111-20/+27
| | | | llvm-svn: 299938
* [SDAG] Reorder expensive StoreMerge Check after cheaper one. NFCNirav Dave2017-04-111-8/+9
| | | | llvm-svn: 299937
* Add MachineRegionInfoPassID to Passes.h.Jan Sjodin2017-04-111-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D31899 llvm-svn: 299932
* GlobalISel: Allow legalizing G_FADD to a libcallDiana Picus2017-04-111-0/+4
| | | | | | | | | Use the same handling in the generic legalizer code as for the other libcalls (G_FREM, G_FPOW). Enable it on ARM for float and double so we can test it. llvm-svn: 299931
* [GlobalISel] LegalizerInfo: Enable legalization of non-power-of-2 typesVolkan Keles2017-04-111-6/+9
| | | | | | | | | | | | | | Summary: Legalize only if the type is marked as Legal or Custom. If not, return Unsupported as LegalizerHelper is not able to handle non-power-of-2 types right now. Reviewers: qcolombet, aditya_nandakumar, dsanders, t.p.northover, kristof.beyls, javed.absar, ab Reviewed By: kristof.beyls, ab Subscribers: dberris, rovka, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D31711 llvm-svn: 299929
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-117-12/+12
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* [SelectionDAG] Check CALLSEQ_BEGIN nodes in DelayForLiveRegsSam Parker2017-04-111-1/+2
| | | | | | | | | | | | | | | | | A fix for the bug reported in PR30911. The issue arises when multiple CALLSEQ_BEGIN nodes are unscheduled as the last node to be unscheduled will gain access to the CallResource register. But when a node is being picked, only CALLSEQ_END nodes are checked against the CallResource and have their chains evaluated. This then means that other CALLSEQ_BEGIN nodes can be scheduled before the existing call sequence has been finalised. This patch adds a check against the FrameSetup nodes in DelayForLiveRegs to prevent this from happening. Differential Revision: https://reviews.llvm.org/D31536 llvm-svn: 299926
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-117-12/+12
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* CodeGen: BlockPlacement: Don't always tail-duplicate with no other successor.Kyle Butt2017-04-101-5/+1
| | | | | | | | | | The math works out where it can actually be counter-productive. The probability calculations correctly handle the case where the alternative is 0 probability, rely on those calculations. Includes a test case that demonstrates the problem. llvm-svn: 299892
* CodeGen: BlockPlacement: Minor probability changes.Kyle Butt2017-04-101-24/+32
| | | | | | | Qin may be large, and Succ may be more frequent than BB. Take these both into account when deciding if tail-duplication is profitable. llvm-svn: 299891
* CodeGen: BranchFolding: Merge identical blocks, even if they are short.Kyle Butt2017-04-101-0/+16
| | | | | | | | Merging identical blocks when it doesn't reduce fallthrough. It is common for the blocks created from critical edge splitting to be identical. We would like to merge these blocks whenever doing so would not reduce fallthrough. llvm-svn: 299890
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-102-4/+6
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* [SelectionDAG] TargetLowering::SimplifyDemandedBits how to properly ↵Craig Topper2017-04-101-1/+5
| | | | | | | | | | | | | | | | | | | | | calculate KnownZero bits for ISD::SETCC and ISD::AssertZExt Summary: For SETCC we aren't calculating the KnownZero bits at all. I've copied the code from computeKnownZero over for this. For AssertZExt we were only setting KnownZero for bits that were demanded. But the upper bits are zero whether they were demanded or not. I'm interested in fixing this because my belief is the first part of the ISD::AND handling code in SimplifyDemandedBits largely exists because of these two bugs. In that code we go to computeKnownBits for the LHS and optimize a RHS constant. Because computeKnownBits handles SETCC and AssertZExt correctly we get better information sometimes than when we call SimplifyDemandedBits on the LHS later. With these two issues fixed in SimplifyDemandedBits I was able to remove that computeKnownBits call and still pass all X86 tests. I'll submit that change in a separate patch. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31715 llvm-svn: 299839
* [GlobalISel]: Fix bug where we can report GISelFailure on erased instructionsAditya Nandakumar2017-04-072-38/+26
| | | | | | | | | | | | | The original instruction might get legalized and erased and expanded into intermediate instructions and the intermediate instructions might fail legalization. This end up in reporting GISelFailure on the erased instruction. Instead report GISelFailure on the intermediate instruction which failed legalization. Reviewed by: ab llvm-svn: 299802
* Revert "[SelectionDAG] Enable target specific vector scalarization of calls ↵Simon Dardis2017-04-074-189/+65
| | | | | | | | | | | | | and returns" This reverts commit r299766. This change appears to have broken the MIPS buildbots. Reverting while I investigate. Revert "[mips] Remove usage of debug only variable (NFC)" This reverts commit r299769. Follow up commit. llvm-svn: 299788
* [GlobalISel] implement narrowing for G_CONSTANT.Igor Breger2017-04-071-0/+20
| | | | | | | | | | | | | | Summary: [GlobalISel] implement narrowing for G_CONSTANT. Reviewers: bogner, zvi, t.p.northover Reviewed By: t.p.northover Subscribers: llvm-commits, dberris, rovka, kristof.beyls Differential Revision: https://reviews.llvm.org/D31744 llvm-svn: 299772
* [SelectionDAG] Enable target specific vector scalarization of calls and returnsSimon Dardis2017-04-074-65/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By target hookifying getRegisterType, getNumRegisters, getVectorBreakdown, backends can request that LLVM to scalarize vector types for calls and returns. The MIPS vector ABI requires that vector arguments and returns are passed in integer registers. With SelectionDAG's new hooks, the MIPS backend can now handle LLVM-IR with vector types in calls and returns. E.g. 'call @foo(<4 x i32> %4)'. Previously these cases would be scalarized for the MIPS O32/N32/N64 ABI for calls and returns if vector types were not legal. If vector types were legal, a single 128bit vector argument would be assigned to a single 32 bit / 64 bit integer register. By teaching the MIPS backend to inspect the original types, it can now implement the MIPS vector ABI which requires a particular method of scalarizing vectors. Previously, the MIPS backend relied on clang to scalarize types such as "call @foo(<4 x float> %a) into "call @foo(i32 inreg %1, i32 inreg %2, i32 inreg %3, i32 inreg %4)". This patch enables the MIPS backend to take either form for vector types. Reviewers: zoran.jovanovic, jaydeep, vkalintiris, slthakur Differential Revision: https://reviews.llvm.org/D27845 llvm-svn: 299766
* Turn on -addr-sink-using-gep by default.Eli Friedman2017-04-061-1/+1
| | | | | | | | | The new codepath has been in the tree for years, and there isn't any reason to use two codepaths here. Differential Revision: https://reviews.llvm.org/D30596 llvm-svn: 299723
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-067-23/+31
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
OpenPOWER on IntegriCloud