summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Debug Info: Move the sorting and uniqueing of pieces from emitLocPieces()Adrian Prantl2014-08-112-18/+22
| | | | | | | into buildLocationList(). By keeping the list of Values sorted, DebugLocEntry::Merge can also merge multi-piece entries. llvm-svn: 215384
* Debug info: Refactor DebugLocEntry's Merge function to makeAdrian Prantl2014-08-112-14/+37
| | | | | | | | | | | | buildLocationLists easier to read. The previous implementation conflated the merging of individual pieces and the merging of entire DebugLocEntries. By splitting this functionality into two separate functions the intention of the code should be clearer. llvm-svn: 215383
* PeepholeOptimizer: make parameter ref to SmallPtrSetImplHans Wennborg2014-08-111-2/+2
| | | | | | | This makes the function type independent of the in-line size of LocalMIs. llvm-svn: 215356
* Make this SmallVector size a power of two as suggested by ChandlerHans Wennborg2014-08-111-1/+1
| | | | llvm-svn: 215355
* In Machine CSE pass, the source register of a COPY machine instruction canJiangning Liu2014-08-111-11/+19
| | | | | | | | be propagated to all its users, and this propagation could increase the probability of finding common subexpressions. If the COPY has only one user, the COPY itself can be removed. llvm-svn: 215344
* Re-commit "Increase the size of this SmallVector in PeepholeOptimizer." ↵Hans Wennborg2014-08-111-3/+3
| | | | | | | | | (r215340) This time, also update the function that receives a reference to the SmallPtrSet as a parameter. llvm-svn: 215342
* Revert "Increase the size of this SmallVector in PeepholeOptimizer." (r215340)Hans Wennborg2014-08-111-1/+1
| | | | | | | | | | | | | That broke the build: /data/buildslave/clang-amd64-freebsd/src-llvm/lib/CodeGen/PeepholeOptimizer.cpp:729:46: error: non-const lvalue reference to type 'SmallPtrSet<[...], 8>' cannot bind to a value of unrelated type 'SmallPtrSet<[...], 16>' Changed |= optimizeExtInstr(MI, MBB, LocalMIs); ^~~~~~~~ /data/buildslave/clang-amd64-freebsd/src-llvm/lib/CodeGen/PeepholeOptimizer.cpp:265:49: note: passing argument to parameter 'LocalMIs' here SmallPtrSet<MachineInstr*, 8> &LocalMIs) { ^ llvm-svn: 215341
* Increase the size of this SmallVector in PeepholeOptimizer.Hans Wennborg2014-08-111-1/+1
| | | | | | During a Clang build, the median size of this was 9 llvm-svn: 215340
* Increase the size of SpillPlacement::BlockFrequencies.Hans Wennborg2014-08-111-2/+2
| | | | | | This SmallVector's median size during a Clang build was 7. llvm-svn: 215338
* Increase the size of this SmallVector in CloneNodeWithValues.Hans Wennborg2014-08-111-1/+1
| | | | | | In a Clang bootstrap, the size of this vector was always 6. llvm-svn: 215335
* Increase the size of DwarfAccelTable::TableHeaderData::Atoms.Hans Wennborg2014-08-111-1/+1
| | | | | | During a Clang bootstrap, it seems this SmallVector always contains 3 elements. llvm-svn: 215334
* Add support for scalarizing cttz_zero_undefPetar Jovanovic2014-08-101-0/+1
| | | | | | | | | Follow up to r214266. Add missing case in ScalarizeVectorResult() for cttz_zero_undef. Differential Revision: http://reviews.llvm.org/D4813 llvm-svn: 215330
* CodeGen: switch to a range based for loopSaleem Abdulrasool2014-08-091-3/+4
| | | | | | Use a range based for loop instead of manual iteration. NFC. llvm-svn: 215287
* DebugInfo: Recommit (reverted in r215217, originally committed in r215157) ↵David Blaikie2014-08-081-0/+1
| | | | | | | | | the assertion that no argument variable is overwritten by subsequent argument variables. This turned up a bug in clang where arguments were emitted with duplicate argument numbers (see r215227). llvm-svn: 215228
* Added a TLI hook to signal that the target does not have or does not care aboutPedro Artigas2014-08-082-5/+11
| | | | | | | | floating point exceptions, added use of flag to fold potentially exception raising floating point math in selection DAG. No functionality change, as targets have to explicitly ask for this behavior and none does today. llvm-svn: 215222
* DebugInfo: Remove assertion (added in r215157) that's firing on a blocksDavid Blaikie2014-08-081-1/+0
| | | | | | test in the test-suite while I investigate further. llvm-svn: 215217
* Add missing Interpreter intrinsic lowering for sin, cos and ceilJosh Klontz2014-08-081-0/+12
| | | | llvm-svn: 215209
* [pr19635] Revert most of r170537, and add new testcase.Patrik Hagglund2014-08-081-1/+1
| | | | | | | | Patch provided by Andrey Kuharev. Sorry, r170537 was obviously wrong. llvm-svn: 215190
* [stack protector] Look through bitcasts to get global variableAkira Hatanaka2014-08-071-9/+19
| | | | | | | | | | | | | | | | __stack_chk_guard. Handle the case where the pointer operand of the load instruction that loads the stack guard is not a global variable but instead a bitcast. %StackGuard = load i8** bitcast (i64** @__stack_chk_guard to i8**) call void @llvm.stackprotector(i8* %StackGuard, i8** %StackGuardSlot) Original test case provided by Ana Pazos. This fixes PR20558. llvm-svn: 215167
* DebugInfo: Fix overwriting/loss of inlined arguments to recursively inlined ↵David Blaikie2014-08-071-4/+2
| | | | | | | | | | | | | | | | | | | | | functions. Due to an unnecessary special case, inlined arguments that happened to be from the same function as they were inlined into were misclassified as non-inline arguments and would overwrite the non-inlined arguments. Assert that we never overwrite a function's arguments, and stop misclassifying inlined arguments as non-inline arguments to fix this issue. Excuse the rather crappy test case - handcrafted IR might do better, or someone who understands better how to tickle the inliner to create a recursive inlining situation like this (though it may also be necessary to tickle the variable in a particular way to cause it to be recorded in the MMI side table and go down this particular path for location information). llvm-svn: 215157
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-076-4/+42
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Debugging Utility - optional ability for dumping critical path lengthGerolf Hoflehner2014-08-071-2/+16
| | | | llvm-svn: 215153
* MachineCombiner Pass for selecting faster instruction sequence on AArch64Gerolf Hoflehner2014-08-071-1/+3
| | | | | | | | | | Re-commit of r214832,r21469 with a work-around that avoids the previous problem with gcc build compilers The work-around is to use SmallVector instead of ArrayRef of basic blocks in preservesResourceLen()/MachineCombiner.cpp llvm-svn: 215151
* test commit: remove trailing whitespace.Frederic Riss2014-08-071-2/+2
| | | | llvm-svn: 215138
* [Branch probability] Recompute branch weights of tail-merged basic blocks.Akira Hatanaka2014-08-073-8/+101
| | | | | | | | | | | | | | | BranchFolderPass was not correctly setting the basic block branch weights when tail-merging created or merged blocks. This patch recomutes the weights of tail-merged blocks using the following formula: branch_weight(merged block to successor j) = sum(block_frequency(bb) * branch_probability(bb -> j)) bb is a block that is in the set of merged blocks. <rdar://problem/16256423> llvm-svn: 215135
* Nuke the old JIT.Rafael Espindola2014-08-076-42/+4
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-061-7/+2
| | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r214761. Revert while Reid investigates & provides a reproduction for an assertion failure for this on Windows. llvm-svn: 214999
* Remove the target machine from CCState. Previously it was only usedEric Christopher2014-08-061-5/+4
| | | | | | | | | to get the subtarget and that's accessible from the MachineFunction now. This helps clear the way for smaller changes where we getting a subtarget will require passing in a MachineFunction/Function as well. llvm-svn: 214988
* Improve performance of calculateDbgValueHistory.Adrian Prantl2014-08-061-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | In r210492 the logic of calculateDbgValueHistory was changed to end register variable live ranges at the end of MBB conditionally on the fact that the register was or not clobbered by the function body. This requires an initial scan of all the operands of the function to collect all clobbered registers. In a second pass over all instructions, we compare this set with the set of clobbered registers for the current MachineInstruction. This modification incurred a compilation time regression on some benchmarks: the debug info emission phase takes ~10% more time. While a small performance hit is unavoidable due to the initial scan requirement, we can improve the situation by avoiding to create too many temporary sets and just use lambdas to work directly on the result of the initial scan. Fixes <rdar://problem/17884104> Patch by Frederic Riss! llvm-svn: 214987
* Cleanup collectChangingRegsAdrian Prantl2014-08-061-3/+4
| | | | | | | | | The handling of the epilogue is best expressed as an early exit and there is no reason to look for register defs in DbgValue MIs. Patch by Frederic Riss! llvm-svn: 214986
* Round up the size of byval arguments to MinAlignReid Kleckner2014-08-061-0/+1
| | | | | | | | | | | | | | Otherwise we can end up with an argument frame size that is not a multiple of stack slot size, which is very awkward. This fixes PR20547, which was a bug in x86_64 Sys V vararg handling. However, it's much easier to test this with x86 callee-cleanup functions, which previously ended in "retl $6" instead of "retl $8". This does affect behavior of all backends, but it presumably fixes the same bug in all of them. llvm-svn: 214980
* use register iterators that include self to reduce code duplication in ↵Sanjay Patel2014-08-061-25/+6
| | | | | | | | | | | | | | | | CriticalAntiDepBreaker This patch addresses 2 FIXME comments that I added to CriticalAntiDepBreaker while fixing PR20020. Initialize an MCSubRegIterator and an MCRegAliasIterator to include the self reg. Assuming that works as advertised, there should be functional difference with this patch, just less code. Also, remove the associated asserts - we're setting those values just before, so the asserts don't do anything meaningful. Differential Revision: http://reviews.llvm.org/D4566 llvm-svn: 214973
* DebugInfo: Assert that any CU for which debug_loc lists are emitted, has at ↵David Blaikie2014-08-061-0/+1
| | | | | | | | | | | | | | | | least one range. This was coming in weird debug info that had variables (and hence debug_locs) but was in GMLT mode (because it was missing the 13th field of the compile_unit metadata) so no ranges were constructed. We should always have at least one range for any CU with a debug_loc in it - because the range should cover the debug_loc. The assertion just ensures that the "!= 1" range case inside the subsequent loop doesn't get entered for the case where there are no ranges at all, which should never reach here in the first place. llvm-svn: 214939
* DebugInfo: Move the reference to the CU from the location list entry to the ↵David Blaikie2014-08-054-19/+14
| | | | | | | | | | list itself, since it is constant across an entire list. This simplifies construction and usage while making the data structure smaller. It was a holdover from the days when we didn't have a separate DebugLocList and all we had was a flat list of DebugLocEntries. llvm-svn: 214933
* Optimize vector fabs of bitcasted constant integer values.Sanjay Patel2014-08-051-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow vector fabs operations on bitcasted constant integer values to be optimized in the same way that we already optimize scalar fabs. So for code like this: %bitcast = bitcast i64 18446744069414584320 to <2 x float> ; 0xFFFF_FFFF_0000_0000 %fabs = call <2 x float> @llvm.fabs.v2f32(<2 x float> %bitcast) %ret = bitcast <2 x float> %fabs to i64 Instead of generating something like this: movabsq (constant pool loadi of mask for sign bits) vmovq (move from integer register to vector/fp register) vandps (mask off sign bits) vmovq (move vector/fp register back to integer return register) We should generate: mov (put constant value in return register) I have also removed a redundant clause in the first 'if' statement: N0.getOperand(0).getValueType().isInteger() is the same thing as: IntVT.isInteger() Testcases for x86 and ARM added to existing files that deal with vector fabs. One existing testcase for x86 removed because it is no longer ideal. For more background, please see: http://reviews.llvm.org/D4770 And: http://llvm.org/bugs/show_bug.cgi?id=20354 Differential Revision: http://reviews.llvm.org/D4785 llvm-svn: 214892
* Partially revert r214761 that asserted that all concrete debug info ↵David Blaikie2014-08-051-1/+2
| | | | | | | | variables had DIEs, due to a failure on Darwin. I'll work on a reduction and fix after this. llvm-svn: 214880
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-0549-164/+114
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Changed the liveness tracking in the RegisterScavengerPedro Artigas2014-08-045-71/+83
| | | | | | | | to use register units instead of registers. reviewed by Jakob Stoklund Olesen. llvm-svn: 214798
* [SDAG] Fix a really, really terrible bug in the DAG combiner.Chandler Carruth2014-08-041-2/+2
| | | | | | | | | | | | | | | This code is completely wrong. It is also dead, as if it were to *ever* run, it would crash. Fortunately, after my work to the combiner, it is at least *possible* to reach the code, and llvm-stress has found a test case. Thanks to Patrick for reporting. It would be really good if anyone who remembers how this code works and what it was intended to do could add some more obvious test coverage instead of my completely contrived and reduced test case. My test case was so brittle I left a bread crumb comment in it to help the next person to stumble on it and not know what it was actually testing for. llvm-svn: 214785
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-0493-507/+705
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-042-4/+8
| | | | | | | | | | | | | | instructions within a function, lead to the function itself." Originally reverted in r213432 with flakey failures on an ASan self-host build. After reduction it seems to be the same issue fixed in r213805 (ArgPromo + DebugInfo: Handle updating debug info over multiple applications of argument promotion) and r213952 (by having LiveDebugVariables strip dbg_value intrinsics in functions that are not described by debug info). Though I cannot explain why this failure was flakey... llvm-svn: 214761
* [x86] Don't add nodes to the combined set (and prune subsequentChandler Carruth2014-08-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | combines) until they are legal. Doing it the old way could, when the stars align *just* right, cause a node to get into the combine set prior to being legalized. Then, when the same node showed up as an operand to another node later on (but not so much later on that it had been deleted as dead) we would fail to add it back to the worklist thinking it had already been combined. This would in turn cause it to not be legalized. Fortunately, we can also walk the operands looking for uncombined (and thus potentially un-legalized) nodes late. It will still ensure that we walk all operands of all nodes and send all of them through both the legalizer without changes and the combiner at least once. (Which was the original goal of this). I have a test case for this bug, but it is terribly brittle. For example, it will stop finding the bug the moment I enable the new shuffle lowering. I don't yet have any test case that reliably exercises this bug, and it isn't clear that it will be possible to craft one. It is entirely possible that with the new shuffle lowering the two forms of doing this are precisely equivalent. That doesn't mean we shouldn't take the more conservative approach of insisting on things in the combined set having survived the legalizer. llvm-svn: 214673
* CodeGen: silence a warningSaleem Abdulrasool2014-08-031-2/+1
| | | | | | | | GCC 4.8.2 objects to the tautological condition in the assert as the unsigned value is guaranteed to be >= 0. Simplify the assertion by dropping the tautological condition. llvm-svn: 214671
* fix for PR20354 - Miscompile of fabs due to vectorizationSanjay Patel2014-08-031-1/+5
| | | | | | | | | | This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
* MachineCombiner Pass for selecting faster instructionGerolf Hoflehner2014-08-035-14/+503
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sequence - target independent framework When the DAGcombiner selects instruction sequences it could increase the critical path or resource len. For example, on arm64 there are multiply-accumulate instructions (madd, msub). If e.g. the equivalent multiply-add sequence is not on the crictial path it makes sense to select it instead of the combined, single accumulate instruction (madd/msub). The reason is that the conversion from add+mul to the madd could lengthen the critical path by the latency of the multiply. But the DAGCombiner would always combine and select the madd/msub instruction. This patch uses machine trace metrics to estimate critical path length and resource length of an original instruction sequence vs a combined instruction sequence and picks the faster code based on its estimates. This patch only commits the target independent framework that evaluates and selects code sequences. The machine instruction combiner is turned off for all targets and expected to evolve over time by gradually handling DAGCombiner pattern in the target specific code. This framework lays the groundwork for fixing rdar://16319955 llvm-svn: 214666
* [AArch64] Teach DAGCombiner that converting two consecutive loads into a ↵James Molloy2014-08-021-0/+7
| | | | | | | | vector load is not a good transform when paired loads are available. The combiner was creating Q-register loads and stores, which then had to be spilled because there are no callee-save Q registers! llvm-svn: 214634
* [SDAG] Refactor the code which deletes nodes in the DAG combiner to doChandler Carruth2014-08-021-54/+36
| | | | | | | | | | | | | so using a single helper which adds operands back onto the worklist. Several places didn't rigorously do this but a couple already did. Factoring them together and doing it rigorously is important to delete things recursively early on in the combiner and get a chance to see accurate hasOneUse values. While no existing test cases change, an upcoming patch to add DAG combining logic for PSHUFB requires this to work correctly. llvm-svn: 214623
* Fix issues with ISD::FNEG and ISD::FMA SDNodes where they would not be ↵Owen Anderson2014-08-021-0/+12
| | | | | | | | | | | | constant-folded during DAGCombine in certain circumstances. Unfortunately, the circumstances required to trigger the issue seem to require a pretty specific interaction of DAGCombines, and I haven't been able to find a testcase that reproduces on X86, ARM, or AArch64. The functionality added here is replicated in essentially every other DAG combine, so it seems pretty obviously correct. llvm-svn: 214622
* CodeGen: Remove commented out codeJustin Bogner2014-08-021-2/+0
| | | | | | | These two lines have been commented out for over 4 years. They aren't helping anyone. llvm-svn: 214615
* Attempt to increase the overall happiness of the MSCV-based buildbots.Adrian Prantl2014-08-011-1/+1
| | | | llvm-svn: 214588
OpenPOWER on IntegriCloud