summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-019-73/+301
| | | | | | | | | | | | | | | | | | | | | | | | variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. llvm-svn: 214576
* [SDAG] MorphNodeTo recursively deletes dead operands of the oldChandler Carruth2014-08-011-0/+4
| | | | | | | | | | | | | fromulation of the node, which isn't really the desired behavior from within the combiner or legalizer, but is necessary within ISel. I've added a hopefully helpful comment and fixed the only two places where this took place. Yet another step toward the combiner and legalizer not needing to use update listeners with virtual calls to manage the worklists behind legalization and combining. llvm-svn: 214574
* [SDAG] Begin simplifying the way in which the legalizer deletes nodes.Chandler Carruth2014-08-011-41/+25
| | | | | | | | | | | | | | | | | | | | This lifts the (very few) places the legalizer would delete dead nodes into the outer loop around the legalizer. This is significantly simpler because it doesn't require the legalizer itself to manage the iterator validity, and it doesn't require the legalizer to be a DAG update listener in order to remove things from the legalized set. It also makes the interface much less contrived for the case of the legalizer running inside the last phase of DAG combining. I'm working on centralizing the deletion of nodes during both legalizing and combining as much as possible. My hope is to remove the need for DAG update listeners from the combiner next, which would remove a costly virtual dispatch chain on every deletion. This in turn should allow us to more aggressively delete DAG nodes during combining which will in turn allow us to combine more aggressively by exposing the actual nodes which have single users to the combine phases. llvm-svn: 214546
* Explicitly report runtime stack realignment in StackMap sectionPhilip Reames2014-08-011-1/+4
| | | | | | | | | | | | This change adds code to explicitly mark a function which requires runtime stack realignment as not having a fixed frame size in the StackMap section. As it happens, this is not actually a functional change. The size that would be reported without the check is also "-1", but as far as I can tell, that's an accident. The code change makes this explicit. Note: There's a separate bug in handling of stackmaps and patchpoints in functions which need dynamic frame realignment. The current code assumes that offsets can be calculated from RBP, but realigned frames must use RSP. (There's a variable gap between RBP and the spill slots.) This change set does not address that issue. Reviewers: atrick, ributzka Differential Revision: http://reviews.llvm.org/D4572 llvm-svn: 214534
* [PowerPC] Generate unaligned vector loads using intrinsics instead of ↵Hal Finkel2014-08-011-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | regular loads Altivec vector loads on PowerPC have an interesting property: They always load from an aligned address (by rounding down the address actually provided if necessary). In order to generate an actual unaligned load, you can generate two load instructions, one with the original address, one offset by one vector length, and use a special permutation to extract the bytes desired. When this was originally implemented, I generated these two loads using regular ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with this: The alignment of a load does not contribute to its identity, and SDNodes are uniqued. So, imagine that we have some unaligned load, L1, that is not aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned). Further imagine that there had already existed a load (L1+16)(unaligned) with the same chain operand as the load L1. When (L1+16)(aligned) is created as part of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just now marked as aligned (because the new alignment overwrites the old). But the original users of (L1+16)(unaligned) now get the data intended for the permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists to get its own permutation-based expansion. This was PR19991. A second potential problem has to do with the MMOs on these loads, which can be used by AA during instruction scheduling to break chain-based dependencies. If the new "aligned" loads get the MMO from the original unaligned load, this does not represent the fact that it will load data from below the original address. Normally, this would not matter, but this load might be combined with another load pair for a previous vector, and then the dependency on the otherwise- ignored lower bytes can matter. To fix both problems, instead of generating the necessary loads using regular ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are provided with MMOs with a conservative address range. Unfortunately, I no longer have a failing test case (since PR19991 was reported, other changes in CodeGen have forced this bug back into hiding it again). Nevertheless, this should fix the underlying problem. llvm-svn: 214481
* White space fix.Louis Gerbarg2014-07-311-1/+1
| | | | llvm-svn: 214455
* Make sure no loads resulting from load->switch DAGCombine are marked invariantLouis Gerbarg2014-07-316-40/+53
| | | | | | | | | | | | | | Currently when DAGCombine converts loads feeding a switch into a switch of addresses feeding a load the new load inherits the isInvariant flag of the left side. This is incorrect since invariant loads can be reordered in cases where it is illegal to reoarder normal loads. This patch adds an isInvariant parameter to getExtLoad() and updates all call sites to pass in the data if they have it or false if they don't. It also changes the DAGCombine to use that data to make the right decision when creating the new load. llvm-svn: 214449
* Disable IsSub subregister assert. pr18663.Will Schmidt2014-07-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow-up to the activity in the bug at http://llvm.org/bugs/show_bug.cgi?id=18663 . The underlying issue has to do with how the KILL pseudo-instruction is handled. I defer to Hal/Jakob/Uli for additional details and background. This will disable the (bad?) assert, add an associated fixme comment, and add a pair of tests. The code change and the pr18663-2.ll test are copied from the referenced bug. That test does not immediately fail in my environment, but I have added the pr18663.ll test which does. (Comment from Hal) to provide everyone else with some context, this assert was not bad when it was written. At that time, we only generated KILL pseudo instructions around subregister copies. This logic, unfortunately, had its own problems. In r199797, the relevant logic in MachineCopyPropagation was replaced to generate KILLs for other kinds of copies too. This change in semantics broke this now-problematic assumption in AggressiveAntiDepBreaker. The AggressiveAntiDepBreaker really needs a proper cleanup to deal with the change, but removing the assert (which just allows the function to return false) is a safe conservative behavior, and should do for the time being. llvm-svn: 214429
* [FastISel] Fix the patchpoint intrinsic lowering in FastISel for large ↵Juergen Ributzka2014-07-311-1/+1
| | | | | | | | | target addresses. This fixes a mistake where I accidentially dropped the upper 32bit of a 64bit pointer during FastISel lowering of the patchpoint intrinsic. llvm-svn: 214367
* Refactor duplicated code.Rafael Espindola2014-07-302-24/+29
| | | | llvm-svn: 214328
* Retain alignment requirements for load->selects modified by DAGCombineLouis Gerbarg2014-07-301-2/+6
| | | | | | | | | | | | | | | | | DAGCombine may choose to rewrite graphs where two loads feed a select into graphs where a select of two addresses feed a load. While it sanity checks the loads to make sure they are broadly equivalent it currently just uses the alignment restriction of the left node. In cases where the right node has stronger alignment requiresment this may lead to bad codegen, such as generating an aligned load where an unaligned load is required. This patch makes the combine generate a load with an alignment that is the same as whichever is more restrictive of the two alignments. Tests included. rdar://17762530 llvm-svn: 214322
* Add the missing hasLinkOnceODRLinkage predicate.Rafael Espindola2014-07-301-2/+1
| | | | llvm-svn: 214312
* Don't manually (and forcibly) run the verifier on the entire module fromChandler Carruth2014-07-301-4/+0
| | | | | | | | | | | | | the jump instruction table pass. First, the verifier is already built into all the tools. The test case is adapted to just run llvm-as demonstrating that we still catch the broken module. Second, the verifier is *extremely* slow. This was responsible for very significant compile time regressions. If you have deployed a Clang binary anywhere from r210280 to this commit, you really want to re-deploy. llvm-svn: 214287
* Add support for scalarizing ctlz_zero_undefPetar Jovanovic2014-07-301-0/+1
| | | | | | | | | Fix the missing case in ScalarizeVectorResult() that was exposed with libclcore.bc in Android. Differential Revision: http://reviews.llvm.org/D4645 llvm-svn: 214266
* Header hygiene: remove using directive and #undef DEBUG_TYPE once we're done.Richard Smith2014-07-301-0/+2
| | | | llvm-svn: 214263
* Feedback on r214189, no functionality change.Manman Ren2014-07-292-2/+2
| | | | llvm-svn: 214240
OpenPOWER on IntegriCloud