summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
* Add nullptr checks for TargetSelectionDAGInfo in SelectionDAG.Manuel Jacob2015-01-281-13/+19
| | | | | | TSI is not guaranteed be non-null in SelectionDAG. llvm-svn: 227397
* Revert r227242 - Merge vector stores into wider vector stores (PR21711).Quentin Colombet2015-01-271-54/+30
| | | | | | | This commit creates infinite loop in DAG combine for in the LLVM test-suite for aarch64 with mcpu=cylcone (just having neon may be enough to expose this). llvm-svn: 227272
* Merge vector stores into wider vector stores (PR21711)Sanjay Patel2015-01-271-30/+54
| | | | | | | | | | | | | | | | | | | | This patch resolves part of PR21711 ( http://llvm.org/bugs/show_bug.cgi?id=21711 ). The 'f3' test case in that report presents a situation where we have two 128-bit stores extracted from a 256-bit source vector. Instead of producing this: vmovaps %xmm0, (%rdi) vextractf128 $1, %ymm0, 16(%rdi) This patch merges the 128-bit stores into a single 256-bit store: vmovups %ymm0, (%rdi) Differential Revision: http://reviews.llvm.org/D7208 llvm-svn: 227242
* Add a FIXME in SelectionDAGBuilder before an assert that is valid only on X86.Manuel Jacob2015-01-271-0/+3
| | | | | | | | | When lowering memcpy, memset or memmove, this assert checks whether the pointer operands are in an address space < 256 which means "user defined address space" on X86. However, this notion of "user defined address space" does not exist for other targets. llvm-svn: 227191
* Grab the TargetLowering info from the DAG rather than querying forEric Christopher2015-01-271-3/+2
| | | | | | a subtarget. llvm-svn: 227156
* [SelectionDAG] Fix assert message copypasta. NFC.Ahmed Bougacha2015-01-261-2/+2
| | | | llvm-svn: 227119
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-263-4/+4
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* Revert GCStrategy ownership changesPhilip Reames2015-01-263-3/+3
| | | | | | | | | | | | This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways. The bugs were: - Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely. - GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times. Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/. llvm-svn: 227109
* [DAG] Fix wrong canonicalization performed on shuffle nodes.Andrea Di Biagio2015-01-241-7/+9
| | | | | | | | | | | This fixes a regression introduced by r226816. When replacing a splat shuffle node with a constant build_vector, make sure that the new build_vector has a valid number of elements. Thanks to Patrik Hagglund for reporting this problem and providing a small reproducible. llvm-svn: 227002
* Classify functions by EH personality type rather than using the tripleReid Kleckner2015-01-231-4/+7
| | | | | | | | | | | | | | | This mostly reverts commit r222062 and replaces it with a new enum. At some point this enum will grow at least for other MSVC EH personalities. Also beefs up the way we were sniffing the personality function. Previously we would emit the Itanium LSDA despite using __C_specific_handler. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6987 llvm-svn: 226920
* DAGCombine: always constant fold FMA when target disable FP exceptionsMehdi Amini2015-01-231-1/+1
| | | | | | | | | | | | | | | | | Summary: When trying to constant fold an FMA in the DAG, getNode() fails to fold the FMA if an operand is not finite. In this case this patch allows the constant folding if !TLI->hasFloatingPointExceptions() Reviewers: resistor Reviewed By: resistor Subscribers: hfinkel, llvm-commits Differential Revision: http://reviews.llvm.org/D6912 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 226901
* SelectionDAG: Add KnownBits and SignBits computation for EXTRACT_ELEMENTJan Vesely2015-01-221-0/+30
| | | | | | | | | | | | v2: use getZExtValue add missing break codestyle v3: add few more comments Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com> llvm-svn: 226880
* Intrinsics: introduce llvm_any_ty aka ValueType AnyRamkumar Ramachandra2015-01-221-1/+2
| | | | | | | | | | | | | | | Specifically, gc.result benefits from this greatly. Instead of: gc.result.int.* gc.result.float.* gc.result.ptr.* ... We now have a gc.result.* that can specialize to literally any type. Differential Revision: http://reviews.llvm.org/D7020 llvm-svn: 226857
* merge consecutive stores of extracted vector elements (PR21711)Sanjay Patel2015-01-221-92/+162
| | | | | | | | | | | | | | | | | | This is a 2nd try at the same optimization as http://reviews.llvm.org/D6698. That patch was checked in at r224611, but reverted at r225031 because it caused a failure outside of the regression tests. The cause of the crash was not recognizing consecutive stores that have mixed source values (loads and vector element extracts), so this patch adds a check to bail out if any store value is not coming from a vector element extract. This patch also refactors the shared logic of the constant source and vector extracted elements source cases into a helper function. Differential Revision: http://reviews.llvm.org/D6850 llvm-svn: 226845
* [DAGCombine] Produce better code for constant splatsMichael Kuperstein2015-01-222-2/+41
| | | | | | | | | | | This solves PR22276. Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead. Differential Revision: http://reviews.llvm.org/D7093 Fixed recommit of r226811. llvm-svn: 226816
* Revert r226811, MSVC accepts code sane compilers don't.Michael Kuperstein2015-01-222-41/+2
| | | | llvm-svn: 226814
* [DAGCombine] Produce better code for constant splatsMichael Kuperstein2015-01-222-2/+41
| | | | | | | | | This solves PR22276. Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead. Differential Revision: http://reviews.llvm.org/D7093 llvm-svn: 226811
* Fixed a bug in type legalizer for masked load/store intrinsics.Elena Demikhovsky2015-01-226-38/+85
| | | | | | | | | | | | The problem occurs when after vectorization we have type <2 x i32>. This type is promoted to <2 x i64> and then requires additional efforts for expanding loads and truncating stores. I added EXPAND / TRUNCATE attributes to the masked load/store SDNodes. The code now contains additional shuffles. I've prepared changes in the cost estimation for masked memory operations, it will be submitted separately. llvm-svn: 226808
* Fixed a commentElena Demikhovsky2015-01-221-1/+1
| | | | llvm-svn: 226806
* Fixed a bug in narrowing store operation.Elena Demikhovsky2015-01-221-2/+5
| | | | | | | | | Type MVT::i1 became legal in KNL, but store operation can't be narrowed to this type, since the size of VT (1 bit) is not equal to its actual store size(8 bits). Added a test provided by David (dag@cray.com) llvm-svn: 226805
* DAGCombine: fold (or (and X, M), (and X, N)) -> (and X, (or M, N))Tim Northover2015-01-211-0/+11
| | | | | | | It can help with argument juggling on some targets, and is generally a good idea. llvm-svn: 226740
* Revert "DAGCombine: fold (or (and X, M), (and X, N)) -> (and X, (or M, N))"Tim Northover2015-01-211-11/+0
| | | | | | | | It hadn't gone through review yet, but was still on my local copy. This reverts commit r226663 llvm-svn: 226665
* DAGCombine: fold (or (and X, M), (and X, N)) -> (and X, (or M, N))Tim Northover2015-01-211-0/+11
| | | | llvm-svn: 226663
* Prevent binary-tree deterioration in sparse switch statements.Daniel Jasper2015-01-201-8/+10
| | | | | | | | | | | | | This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
* Factor out a splitSwitchCase() function so that it can be reused.Daniel Jasper2015-01-202-21/+26
| | | | | | | | | | | | | | This is in preparation for a fix to llvm.org/PR22262. One of the ideas here is to first find a good jump table range first and then split before and after it. Thereby, we don't need to use the split-based-on-density heuristic at all, which can make the "binary tree" deteriorate in various cases. Also some minor cleanups. No functional changes. llvm-svn: 226551
* [PM] Remove the Pass argument from all of the critical edge splittingChandler Carruth2015-01-191-4/+5
| | | | | | | | | | | | | | | | | | | APIs and replace it and numerous booleans with an option struct. The critical edge splitting API has a really large surface of flags and so it seems worth burning a small option struct / builder. This struct can be constructed with the various preserved analyses and then flags can be flipped in a builder style. The various users are now responsible for directly passing along their analysis information. This should be enough for the critical edge splitting to work cleanly with the new pass manager as well. This API is still pretty crufty and could be cleaned up a lot, but I've focused on this change just threading an option struct rather than a pass through the API. llvm-svn: 226456
* Improve DAG combine pass on certain IR vector patternsMehdi Amini2015-01-171-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loading 2 2x32-bit float vectors into the bottom half of a 256-bit vector produced suboptimal code in AVX2 mode with certain IR combinations. In particular, the IR optimizer folded 2f32 + 2f32 -> 4f32, 4f32 + 4f32 (undef) -> 8f32 into a 2f32 + 2f32 -> 8f32, which seems more canonical, but then mysteriously generated rather bad code; the movq/movhpd combination didn't match. The problem lay in the BUILD_VECTOR optimization path. The 2f32 inputs would get promoted to 4f32 by the type legalizer, eventually resulting in a BUILD_VECTOR on two 4f32 into an 8f32. The BUILD_VECTOR then, recognizing these were both half the output size, concatted them and then produced a shuffle. However, the resulting concat + shuffle was more complex than it should be; in the case where the upper half of the output is undef, we probably want to generate shuffle + concat instead. This enhancement causes the vector_shuffle combine step to recognize this suboptimal pattern and correct it. I included it there instead of in BUILD_VECTOR in case the same suboptimal pattern occurs for other reasons. This results in the optimizer correctly producing the optimal movq + movhpd sequence for all three variations on this IR, even with AVX2. I've included a test case. Radar link: rdar://problem/19287012 Fix for PR 21943. From: Fiona Glaser <fglaser@apple.com> llvm-svn: 226360
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-163-3/+4
| | | | | | | | | | | | Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions. Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance. In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.) Differential Revision: http://reviews.llvm.org/D6811 llvm-svn: 226311
* Fix SelectionDAG -view-*-dags filteringMehdi Amini2015-01-151-1/+1
| | | | llvm-svn: 226163
* Replace size method call of containers to empty method where appropriateAlexander Kornienko2015-01-151-1/+1
| | | | | | | | | | | | | | | | This patch was generated by a clang tidy checker that is being open sourced. The documentation of that checker is the following: /// The emptiness of a container should be checked using the empty method /// instead of the size method. It is not guaranteed that size is a /// constant-time function, and it is generally more efficient and also shows /// clearer intent to use empty. Furthermore some containers may implement the /// empty method but not implement the size method. Using empty whenever /// possible makes it easier to switch to another container in the future. Patch by Gábor Horváth! llvm-svn: 226161
* [PM] Separate the TargetLibraryInfo object from the immutable pass.Chandler Carruth2015-01-151-3/+4
| | | | | | | | | | | | | | The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-153-3/+3
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Emit the Itanium LSDA for unknown EH personalities on Win64Reid Kleckner2015-01-141-0/+4
| | | | | | | | | | This fixes lots of generic CodeGen tests that use __gcc_personality_v0. This suggests that using ExceptionHandling::MSVC was a mistake, and we should instead classify each function by personality function. This would, for example, allow us to LTO a binary containing uses of SEH and Itanium EH. llvm-svn: 226019
* Remove dead code for llvm.eh.selector in the old EH modelReid Kleckner2015-01-141-54/+0
| | | | llvm-svn: 226018
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-143-3/+3
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* SelectionDAG: add a -filter-view-dags option to llcMehdi Amini2015-01-141-10/+25
| | | | | | | | | This option takes the name of the basic block you want to visualize with -view-*-dags Differential Revision: http://reviews.llvm.org/D6948 llvm-svn: 225953
* DAG Combiner: Fold SelectCC When Cond is UNDEFMehdi Amini2015-01-141-4/+7
| | | | | | | | | In case folding a node end up with a NaN as operand for the select, the folding of the condition of the selectcc node returns "UNDEF". Differential Revision: http://reviews.llvm.org/D6889 llvm-svn: 225952
* Implement new way of expanding extloads.Matt Arsenault2015-01-142-16/+19
| | | | | | | | | | | | | | | Now that the source and destination types can be specified, allow doing an expansion that doesn't use an EXTLOAD of the result type. Try to do a legal extload to an intermediate type and extend that if possible. This generalizes the special case custom lowering of extloads R600 has been using to work around this problem. This also happens to fix a bug that would incorrectly use more aligned loads than should be used. llvm-svn: 225925
* Adjust ScheduleDAGSDNodes::RegDefIter for patchpointsHal Finkel2015-01-141-0/+8
| | | | | | | | | | | | | | | PATCHPOINT is a strange pseudo-instruction. Depending on how it is used, and whether or not the AnyReg calling convention is being used, it might or might not define a value. However, its TableGen definition says that it defines one value, and so when it doesn't, the code in ScheduleDAGSDNodes::RegDefIter becomes confused and the code that uses the RegDefIter will try to get the register class of the MVT::Other type associated with the PATCHPOINT's chain result (under certain circumstances). This will be covered by the PPC64 PatchPoint test cases once that support is re-committed. llvm-svn: 225907
* CodeGen support for x86_64 SEH catch handlers in LLVMReid Kleckner2015-01-143-5/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds handling for ExceptionHandling::MSVC, used by the x86_64-pc-windows-msvc triple. It assumes that filter functions have already been outlined in either the frontend or the backend. Filter functions are used in place of the landingpad catch clause type info operands. In catch clause order, the first filter to return true will catch the exception. The C specific handler table expects the landing pad to be split into one block per handler, but LLVM IR uses a single landing pad for all possible unwind actions. This patch papers over the mismatch by synthesizing single instruction BBs for every catch clause to fill in the EH selector that the landing pad block expects. Missing functionality: - Accessing data in the parent frame from outlined filters - Cleanups (from __finally) are unsupported, as they will require outlining and parent frame access - Filter clauses are unsupported, as there's no clear analogue in SEH In other words, this is the minimal set of changes needed to write IR to catch arbitrary exceptions and resume normal execution. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6300 llvm-svn: 225904
* DAGCombiner: simplify by using condition variables; NFCMatthias Braun2015-01-132-18/+15
| | | | llvm-svn: 225836
* R600: Implement getRecipEstimateMatt Arsenault2015-01-131-1/+2
| | | | | | | | | This requires a new hook to prevent expanding sqrt in terms of rsqrt and reciprocal. v_rcp_f32, v_rsq_f32, and v_sqrt_f32 are all the same rate, so this expansion would just double the number of instructions and cycles. llvm-svn: 225828
* [StackMaps] Mark in CallLoweringInfo when lowering a patchpointHal Finkel2015-01-133-4/+7
| | | | | | | | | | | | | | | While, generally speaking, the process of lowering arguments for a patchpoint is the same as lowering a regular indirect call, on some targets it may not be exactly the same. Targets may not, for example, want to add additional register dependencies that apply only to making cross-DSO calls through linker stubs, may not want to load additional registers out of function descriptors, and may not want to add additional side-effect-causing instructions that cannot be removed later with the call itself being generated. The PowerPC target will use this in a future commit (for all of the reasons stated above). llvm-svn: 225806
* Added TLI hook for isFPExtFree. Some of the FMA combine heuristics are now ↵Olivier Sallenave2015-01-131-63/+70
| | | | | | guarded with that hook. llvm-svn: 225795
* Rename llvm.recoverframeallocation to llvm.framerecoverReid Kleckner2015-01-131-3/+3
| | | | | | | | This name is less descriptive, but it sort of puts things in the 'llvm.frame...' namespace, relating it to frameallocate and frameaddress. It also avoids using "allocate" and "allocation" together. llvm-svn: 225752
* Add the llvm.frameallocate and llvm.recoverframeallocation intrinsicsReid Kleckner2015-01-131-0/+53
| | | | | | | | | | | | | | | | | | | | | These intrinsics allow multiple functions to share a single stack allocation from one function's call frame. The function with the allocation may only perform one allocation, and it must be in the entry block. Functions accessing the allocation call llvm.recoverframeallocation with the function whose frame they are accessing and a frame pointer from an active call frame of that function. These intrinsics are very difficult to inline correctly, so the intention is that they be introduced rarely, or at least very late during EH preparation. Reviewers: echristo, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D6493 llvm-svn: 225746
* Combine fcmp + select to fminnum / fmaxnum if no nans and legalMatt Arsenault2015-01-131-0/+59
| | | | | | | Also require unsafe FP math for no since there isn't a way to test for signed zeros. llvm-svn: 225744
* [DAGCombine] Remainder of fix to r225380 (More FMA folding opportunities)Hal Finkel2015-01-091-10/+24
| | | | | | | | | | As pointed out by Aditya (and Owen), when we elide an FP extend to form an FMA, we need to extend the incoming operands so that the resulting node will really be legal. This is currently enabled only for PowerPC, and it happens to work there regardless, but this should fix the functionality for everyone else should anyone else wish to use it. llvm-svn: 225492
* Partial fix to r225380 (More FMA folding opportunities)Hal Finkel2015-01-091-96/+95
| | | | | | | | | | | | As pointed out by Aditya (and Owen), there are two things wrong with this code. First, it adds patterns which elide FP extends when forming FMAs, and that might not be profitable on all targets (it belongs behind the pre-existing aggressive-FMA-formation flag). This is fixed by this change. Second, the resulting nodes might have operands of different types (the extensions need to be re-added). That will be fixed in the follow-up commit. llvm-svn: 225485
* Masked Load/Store - fixed a bug in type legalization.Elena Demikhovsky2015-01-083-3/+107
| | | | llvm-svn: 225441
OpenPOWER on IntegriCloud