summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [WinEH] Avoid infinite loop in BranchFolding for multiple single block funcletsAndrew Kaylor2015-12-031-0/+8
| | | | | | Differential Revision: http://reviews.llvm.org/D14996 llvm-svn: 254629
* Revert "ScheduleDAGInstrs: Rework schedule graph builder."Matthias Braun2015-12-031-159/+66
| | | | | | | | | | This works mostly fine but breaks some stage 1 builders when compiling compiler-rt on i386. Revert for further investigation as I can't see an obvious cause/fix. This reverts commit r254577. llvm-svn: 254586
* ScheduleDAGInstrs: Rework schedule graph builder.Matthias Braun2015-12-031-66/+159
| | | | | | | | | | | | | | | The new algorithm remembers the uses encountered while walking backwards until a matching def is found. Contrary to the previous version this: - Works without LiveIntervals being available - Allows to increase the precision to subregisters/lanemasks (not used for now) The changes in the AMDGPU tests are necessary because the R600 scheduler is not stable with respect to the order of nodes in the ready queues. Differential Revision: http://reviews.llvm.org/D9068 llvm-svn: 254577
* RegisterPressure: Use range based for, fix else style; NFCMatthias Braun2015-12-031-41/+28
| | | | llvm-svn: 254575
* Move EH-specific helper functions to a more appropriate placeDavid Majnemer2015-12-026-6/+6
| | | | | | No functionality change is intended. llvm-svn: 254562
* Use std::string instead of strdup() and free() in WinCodeViewLineTablesReid Kleckner2015-12-022-15/+6
| | | | llvm-svn: 254557
* [CodeGen]: Fix bad interaction with AntiDep breaking and inline asm.Kyle Butt2015-12-021-3/+6
| | | | | | | | | AggressiveAntiDepBreaker was renaming registers specified by the user for inline assembly. While this will work for compiler-specified registers, it won't work for user-specified registers, and at the time this runs, I don't currently see a way to distinguish them. llvm-svn: 254532
* Fix accidental off by one changeFiona Glaser2015-12-021-1/+1
| | | | | | Didn't break any tests, but did unnecessary extra work. llvm-svn: 254529
* Scheduler / Regalloc: use unique_ptr[] instead of std::vectorFiona Glaser2015-12-022-15/+16
| | | | | | | | | vector.resize() is significantly slower than memset in many STLs and the cost of initializing these vectors is significant on targets with many registers. Since we don't need the overhead of a vector, use a simple unique_ptr instead. llvm-svn: 254526
* AArch64: use ldxp/stxp pair to implement 128-bit atomic loads.Tim Northover2015-12-021-30/+38
| | | | | | | | The ARM ARM is clear that 128-bit loads are only guaranteed to have been atomic if there has been a corresponding successful stxp. It's less clear for AArch32, so I'm leaving that alone for now. llvm-svn: 254524
* Fix a bug in IfConversion.cpp.Cong Hou2015-12-011-3/+2
| | | | | | | | The bug is introduced in r254377 which failed some tests on ARM, where a new probability is assigned to a successor but the provided BB may not be a successor. llvm-svn: 254463
* use range-based for loops; NFCISanjay Patel2015-12-011-12/+6
| | | | llvm-svn: 254453
* don't repeat function/variable names in comments; NFCSanjay Patel2015-12-011-64/+57
| | | | llvm-svn: 254445
* fix typo; NFCSanjay Patel2015-12-011-1/+1
| | | | llvm-svn: 254442
* Fixed a failure in cost calculation for vector GEPElena Demikhovsky2015-12-011-8/+8
| | | | | | | | | Cost calculation for vector GEP failed with due to invalid cast to GEP index operand. The bug is fixed, added a test. http://reviews.llvm.org/D14976 llvm-svn: 254408
* Introduce new @llvm.get.dynamic.area.offset.i{32, 64} intrinsics.Yury Gribov2015-12-015-0/+34
| | | | | | | | | | | | | | | The @llvm.get.dynamic.area.offset.* intrinsic family is used to get the offset from native stack pointer to the address of the most recent dynamic alloca on the caller's stack. These intrinsics are intendend for use in combination with @llvm.stacksave and @llvm.restore to get a pointer to the most recent dynamic alloca. This is useful, for example, for AddressSanitizer's stack unpoisoning routines. Patch by Max Ostapenko. Differential Revision: http://reviews.llvm.org/D14983 llvm-svn: 254404
* Allow known and unknown probabilities coexist in MBB's successor list.Cong Hou2015-12-011-8/+17
| | | | | | | | | | Previously it is not allowed for each MBB to have successors with both known and unknown probabilities. However, this may be too strict as at this stage we could not always guarantee that. It is better to remove this restriction now, and I will work on validating MBB's successors' probabilities first (for example, check if the sum is approximate one). llvm-svn: 254402
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-018-303/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. (This is the second attempt to submit this patch. The first caused two assertion failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687) The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254377
* RegisterPressure: If we do not collect dead defs the list must be emptyMatthias Braun2015-12-011-5/+1
| | | | llvm-svn: 254372
* RegisterPressure: Remove support for recede()/advance() at MBB boundariesMatthias Braun2015-12-011-18/+5
| | | | | | | Nobody was checking the returnvalue of recede()/advance() so we can simply replace this code with asserts. llvm-svn: 254371
* RegisterPressure: Split RegisterOperands analysis code from result object; NFCMatthias Braun2015-12-011-43/+60
| | | | | | | This is in preparation to expose the RegisterOperands class as RegisterPressure API. llvm-svn: 254368
* Revert r254348: "Replace all weight-based interfaces in MBB with ↵Hans Wennborg2015-12-018-171/+301
| | | | | | | | | | probability-based interfaces, and update all uses of old interfaces." and the follow-up r254356: "Fix a bug in MachineBlockPlacement that may cause assertion failure during BranchProbability construction." Asserts were firing in Chromium builds. See PR25687. llvm-svn: 254366
* Fix a bug in MachineBlockPlacement that may cause assertion failure during ↵Cong Hou2015-12-011-3/+7
| | | | | | | | BranchProbability construction. The root cause is the rounding behavior in BranchProbability construction. We may consider to use truncation instead in the future. llvm-svn: 254356
* Extend debug info for function parameters in SDAG.Evgeniy Stepanov2015-12-011-16/+11
| | | | | | | | | | | | | SDAG currently can emit debug location for function parameters when an llvm.dbg.declare points to either a function argument SSA temp, or to an AllocaInst. This change extends this logic by adding a fallback case when neither of the above is true. This is required for SafeStack, which may copy the contents of a byval function argument into something that is not an alloca, and then describe the target as the new location of the said argument. llvm-svn: 254352
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-018-301/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254348
* Have 'optnone' respect the -fast-isel=false option.Paul Robinson2015-11-302-4/+9
| | | | | | | | This is primarily useful for debugging optnone v. ISel issues. Differential Revision: http://reviews.llvm.org/D14792 llvm-svn: 254335
* Use a lambda instead of std::bind and std::mem_fn I introduced in r254242. NFCCraig Topper2015-11-291-2/+3
| | | | llvm-svn: 254260
* [SelectionDAG] Use std::any_of instead of a manually coded loop. NFCCraig Topper2015-11-291-8/+4
| | | | llvm-svn: 254242
* [Stack realignment] Handling of aligned allocas.Jonas Paulsson2015-11-281-13/+15
| | | | | | | | | | | | | | | | | | | | This patch implements dynamic realignment of stack objects for targets with a non-realigned stack pointer. Behaviour in FunctionLoweringInfo is changed so that for a target that has StackRealignable set to false, over-aligned static allocas are considered to be variable-sized objects and are handled with DYNAMIC_STACKALLOC nodes. It would be good to group aligned allocas into a single big alloca as an optimization, but this is yet todo. SystemZ benefits from this, due to its stack frame layout. New tests SystemZ/alloca-03.ll for aligned allocas, and SystemZ/alloca-04.ll for "no-realign-stack" attribute on functions. Review and help from Ulrich Weigand and Hal Finkel. llvm-svn: 254227
* Expose isXxxConstant() functions from SelectionDAGNodes.h (NFC)Artyom Skrobov2015-11-252-20/+20
| | | | | | | | | | | | | | Summary: Many target lowerings copy-paste the code to test SDValues for known constants. This code can instead be shared in SelectionDAG.cpp, and reused in the targets. Reviewers: MatzeB, andreadb, tstellarAMD Subscribers: arsenm, jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D14945 llvm-svn: 254085
* Fix some places where we were assuming that memory type had been legalizedEric Christopher2015-11-252-3/+2
| | | | | | | | | | to a simple type when lowering a truncating store of a vector type. In this case for an EVT we'll return Expand as we should in all of the cases anyhow. The testcase triggered at the one in VectorLegalizer::LegalizeOp, inspection found the rest. llvm-svn: 254061
* LiveVariables should not clobber MachineOperand::IsDead, ::IsKill on ↵Matthias Braun2015-11-241-2/+6
| | | | | | | | | | reserved physical registers Patch by Nick Johnson <Nicholas.Paul.Johnson@deshawresearch.com> Differential Revision: http://reviews.llvm.org/D14875 llvm-svn: 254012
* Let SelectionDAG start to use probability-based interface to add successors.Cong Hou2015-11-245-217/+248
| | | | | | | | | | | | | | | | | | | | | | | | The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes. 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights. 3. Use new interfaces in all other passes. 4. Remove old interfaces. This the second patch above. In this patch SelectionDAG starts to use probability-based interfaces in MBB to add successors but other MC passes are still using weight-based interfaces. Therefore, we need to maintain correct weight list in MBB even when probability-based interfaces are used. This is done by updating weight list in probability-based interfaces by treating the numerator of probabilities as weights. This change affects many test cases that check successor weight values. I will update those test cases once this patch looks good to you. Differential revision: http://reviews.llvm.org/D14361 llvm-svn: 253965
* [DIE] Make DIE.h NDEBUG conditional-free.Davide Italiano2015-11-241-26/+18
| | | | | | Switch dump()/print() method definitions to LLVM_DUMP_METHOD instead. llvm-svn: 253945
* [WinEH] Fix problem where CodeGenPrepare incorrectly sinks a bitcast into an ↵Andrew Kaylor2015-11-231-0/+6
| | | | | | | | EH pad. Differential Revision: http://reviews.llvm.org/D14842 llvm-svn: 253902
* Remove duplicate getValueType() calls. NFCI.Simon Pilgrim2015-11-221-2/+2
| | | | llvm-svn: 253823
* Avoid dependency between TableGen and CodeGenKrzysztof Parzyszek2015-11-221-0/+27
| | | | | | | | Duplicate a few common definitions between DFAPacketizer.cpp and DFAPacketizerEmitter.cpp to avoid including files from CodeGen in TableGen. llvm-svn: 253820
* Hexagon V60/HVX DFA scheduler supportKrzysztof Parzyszek2015-11-211-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended DFA tablegen to: - added "-debug-only dfa-emitter" support to llvm-tblgen - defined CVI_PIPE* resources for the V60 vector coprocessor - allow specification of multiple required resources - supports ANDs of ORs - e.g. [SLOT2, SLOT3], [CVI_MPY0, CVI_MPY1] means: (SLOT2 OR SLOT3) AND (CVI_MPY0 OR CVI_MPY1) - added support for combo resources - allows specifying ORs of ANDs - e.g. [CVI_XLSHF, CVI_MPY01] means: (CVI_XLANE AND CVI_SHIFT) OR (CVI_MPY0 AND CVI_MPY1) - increased DFA input size from 32-bit to 64-bit - allows for a maximum of 4 AND'ed terms of 16 resources - supported expressions now include: expression => term [AND term] [AND term] [AND term] term => resource [OR resource]* resource => one_resource | combo_resource combo_resource => (one_resource [AND one_resource]*) Author: Dan Palermo <dpalermo@codeaurora.org> kparzysz: Verified AMDGPU codegen to be unchanged on all llc tests, except those dealing with instruction encodings. Reapply the previous patch, this time without circular dependencies. llvm-svn: 253793
* Revert r253790: it breaks all builds for some reason.Krzysztof Parzyszek2015-11-211-30/+9
| | | | llvm-svn: 253791
* Hexagon V60/HVX DFA scheduler supportKrzysztof Parzyszek2015-11-211-9/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended DFA tablegen to: - added "-debug-only dfa-emitter" support to llvm-tblgen - defined CVI_PIPE* resources for the V60 vector coprocessor - allow specification of multiple required resources - supports ANDs of ORs - e.g. [SLOT2, SLOT3], [CVI_MPY0, CVI_MPY1] means: (SLOT2 OR SLOT3) AND (CVI_MPY0 OR CVI_MPY1) - added support for combo resources - allows specifying ORs of ANDs - e.g. [CVI_XLSHF, CVI_MPY01] means: (CVI_XLANE AND CVI_SHIFT) OR (CVI_MPY0 AND CVI_MPY1) - increased DFA input size from 32-bit to 64-bit - allows for a maximum of 4 AND'ed terms of 16 resources - supported expressions now include: expression => term [AND term] [AND term] [AND term] term => resource [OR resource]* resource => one_resource | combo_resource combo_resource => (one_resource [AND one_resource]*) Author: Dan Palermo <dpalermo@codeaurora.org> kparzysz: Verified AMDGPU codegen to be unchanged on all llc tests, except those dealing with instruction encodings. llvm-svn: 253790
* [DAGCombiner] Bugfix for lost chain depenedency.Jonas Paulsson2015-11-211-13/+7
| | | | | | | | | | | | | | When MergeConsecutiveStores() combines two loads and two stores into wider loads and stores, the chain users of both of the original loads must be transfered to the new load, because it may be that a chain user only depends on one of the loads. New test case: test/CodeGen/SystemZ/dag-combine-01.ll Reviewed by James Y Knight. Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=25310#c6 llvm-svn: 253779
* [CodeGenPrepare] Create more extloads and fewer andsGeoff Berry2015-11-201-1/+190
| | | | | | | | | | | | | | | Summary: Add and instructions immediately after loads that only have their low bits used, assuming that the (and (load x) c) will be matched as a extload and the ands/truncs fed by the extload will be removed by isel. Reviewers: mcrosier, qcolombet, ab Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14584 llvm-svn: 253722
* [ShrinkWrap] Teach ShrinkWrap to handle targets requiring a register scavenger.Arnaud A. de Grandmaison2015-11-201-15/+22
| | | | | | | | The included test only checks for a compiler crash for now. Several people are facing this issue, so we first resolve the crash, and will increase shrinkwrap's coverage later in a follow-up patch. llvm-svn: 253718
* Partially revert r253662: some unrelated work was accidentally committed ↵Daniel Sanders2015-11-201-1/+0
| | | | | | | | with it. Sorry. llvm-svn: 253663
* Revert the revert 253497 and 253539 - These commits aren't the cause of the ↵Daniel Sanders2015-11-201-0/+1
| | | | | | | | clang-cmake-mips failures. Sorry for the noise. llvm-svn: 253662
* [LTO] Add option to emit assembly from LTOCodeGeneratorTobias Edler von Koch2015-11-191-7/+8
| | | | | | | | | | This adds a new API, LTOCodeGenerator::setFileType, to choose the output file format for LTO CodeGen. A corresponding change to use this new API from llvm-lto and a test case is coming in a separate commit. Differential Revision: http://reviews.llvm.org/D14554 llvm-svn: 253622
* [WinEH] Disable most forms of demotionReid Kleckner2015-11-191-117/+5
| | | | | | | | | | Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
* Expand subregisters in MachineFrameInfo::getPristineRegsKrzysztof Parzyszek2015-11-191-4/+3
| | | | | | http://reviews.llvm.org/D14719 llvm-svn: 253600
* [CGP] despeculate expensive cttz/ctlz intrinsicsSanjay Patel2015-11-191-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another step towards allowing SimplifyCFG to speculate harder, but then have CGP clean things up if the target doesn't like it. Previous patches in this series: http://reviews.llvm.org/D12882 http://reviews.llvm.org/D13297 D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special handling because of weirdness in the intrinsic definition for handling a zero input (that definition can probably be blamed on x86). For example, if we have the usual speculated-by-select expensive op pattern like this: %tobool = icmp eq i64 %A, 0 %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true %cond = select i1 %tobool, i64 64, i64 %0 ret i64 %cond There's an instcombine that will turn it into: %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false This CGP patch is looking for that case and despeculating it back into: entry: %tobool = icmp eq i64 %A, 0 br i1 %tobool, label %cond.end, label %cond.true cond.true: %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true br label %cond.end cond.end: %cond = phi i64 [ %0, %cond.true ], [ 64, %entry ] ret i64 %cond This unfortunately may lead to poorer codegen (see the changes in the existing x86 test), but if we increase speculation in SimplifyCFG (the next step in this patch series), then we should avoid those kinds of cases in the first place. The need for this patch was originally mentioned here: http://reviews.llvm.org/D7506 with follow-up here: http://reviews.llvm.org/D7554 Differential Revision: http://reviews.llvm.org/D14630 llvm-svn: 253573
* X86: More efficient legalization of wide integer comparesHans Wennborg2015-11-195-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, this makes the code for 64-bit compares on 32-bit targets much more efficient. Example: define i32 @test_slt(i64 %a, i64 %b) { entry: %cmp = icmp slt i64 %a, %b br i1 %cmp, label %bb1, label %bb2 bb1: ret i32 1 bb2: ret i32 2 } Before this patch: test_slt: movl 4(%esp), %eax movl 8(%esp), %ecx cmpl 12(%esp), %eax setae %al cmpl 16(%esp), %ecx setge %cl je .LBB2_2 movb %cl, %al .LBB2_2: testb %al, %al jne .LBB2_4 movl $1, %eax retl .LBB2_4: movl $2, %eax retl After this patch: test_slt: movl 4(%esp), %eax movl 8(%esp), %ecx cmpl 12(%esp), %eax sbbl 16(%esp), %ecx jge .LBB1_2 movl $1, %eax retl .LBB1_2: movl $2, %eax retl Differential Revision: http://reviews.llvm.org/D14496 llvm-svn: 253572
OpenPOWER on IntegriCloud