summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/SystemZ/SystemZISelDAGToDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Pass DebugLoc and SDLoc by const ref.Benjamin Kramer2016-06-121-4/+5
| | | | | | | | This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512
* [SystemZ] Enable long displacement constraints for inline ASM operandsUlrich Weigand2016-06-091-5/+18
| | | | | | | | | | | | | | | | | | This enables use of the 'S' constraint for inline ASM operands on SystemZ, which allows for a memory reference with a signed 20-bit immediate displacement. This patch includes corresponding documentation and test case updates. I've changed the 'T' constraint to match the new behavior for 'S', as 'T' also uses a long displacement (though index constraints are still not implemented). I also changed 'm' to match the behavior for 'S' as this will allow for a wider range of displacements for 'm', though correct me if that's not the right decision. Author: colpell Differential Revision: http://reviews.llvm.org/D21097 llvm-svn: 272266
* SDAG: Implement Select instead of SelectImpl in SystemZDAGToDAGISelJustin Bogner2016-05-131-56/+56
| | | | | | | | | | - Where we were returning a node before, call ReplaceNode instead. - Where we would return null to fall back to another selector, rename the method to try* and return a bool for success. Part of llvm.org/pr26808. llvm-svn: 269505
* SDAG: Avoid relying on the return value of SelectCode in SystemZ. NFCJustin Bogner2016-05-101-12/+20
| | | | | | | | | | This is a bit of a spot fix for now. I'll try to fix this up more comprehensively soon. This is part of the work to have Select return void instead of an SDNode *, which is in turn part of llvm.org/pr26808. llvm-svn: 269120
* SDAG: Stop relying on Select's return value in SystemZ's ↵Justin Bogner2016-05-091-14/+38
| | | | | | | | | | | | | | | splitLargeImmediate. NFC The call to Select on Upper here happens in an unusual order in order to defeat the constant folding that getNode() does. Add a comment explaining why we can't just move the Select to later to avoid a Handle, and wrap the call to SelectCode in a handle so we don't need its return value. This is part of the work to have Select return void instead of an SDNode *, which is in turn part of llvm.org/pr26808. llvm-svn: 268990
* SDAG: Rename Select->SelectImpl and repurpose Select as returning voidJustin Bogner2016-05-051-3/+4
| | | | | | | | | | | | | | This is a step towards removing the rampant undefined behaviour in SelectionDAG, which is a part of llvm.org/PR26808. We rename SelectionDAGISel::Select to SelectImpl and update targets to match, and then change Select to return void and consolidate the sketchy behaviour we're trying to get away from there. Next, we'll update backends to implement `void Select(...)` instead of SelectImpl and eventually drop the base Select implementation. llvm-svn: 268693
* [SystemZ] Implement llvm.get.dynamic.area.offsetMarcin Koscielnicki2016-05-041-0/+4
| | | | | | | | To be used for AddressSanitizer. Differential Revision: http://reviews.llvm.org/D19817 llvm-svn: 268572
* SystemZ: Remove implicit ilist iterator conversion, NFCDuncan P. N. Exon Smith2015-10-201-1/+1
| | | | llvm-svn: 250790
* [DAGCombiner] Attempt to mask vectors before zero extension instead of after.Simon Pilgrim2015-08-151-3/+19
| | | | | | | | | | | | | | For cases where we TRUNCATE and then ZERO_EXTEND to a larger size (often from vector legalization), see if we can mask the source data and then ZERO_EXTEND (instead of after a ANY_EXTEND). This can help avoid having to generate a larger mask, and possibly applying it to several sub-vectors. (zext (truncate x)) -> (zext (and(x, m)) Includes a minor patch to SystemZ to better recognise 8/16-bit zero extension patterns from RISBG bit-extraction code. This is the first of a number of minor patches to help improve the conversion of byte masks to clear mask shuffles. Differential Revision: http://reviews.llvm.org/D11764 llvm-svn: 245160
* [SystemZ] Only attempt RxSBG optimization for integer typesUlrich Weigand2015-06-251-2/+7
| | | | | | | | | | | | As pointed out by Justin Bogner (see r240520), SystemZDAGToDAGISel::Select currently attempts to convert boolean operations into RxSBG even on some non-integer types (in particular, vector types). This would not work in any case, and it happened to trigger undefined behaviour in allOnes. This patch verifies that we have a (<= 64-bit) integer type before attempting to perform this optimization. llvm-svn: 240634
* SystemZ: Rephrase this allOnes calculation to avoid UBJustin Bogner2015-06-241-1/+3
| | | | | | | | | | | | | This allOnes function hits undefined behaviour if Count is greater than 64, but we can avoid that and simplify the calculation by just saturating if such a value is passed in. This comes up under ubsan becauseRxSBGOperands is sometimes created with values that are 128 bits wide. Somebody more familiar with this code should probably look into whether that's expected, as a 64 bit mask may or may not be appropriate for such types. llvm-svn: 240520
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-171-2/+2
| | | | | | | | | | | | that it is its own entity in the form of MemoryLocation, and update all the callers. This is an entirely mechanical change. References to "Location" within AA subclases become "MemoryLocation", and elsewhere "AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps out-of-tree folks update. llvm-svn: 239885
* [SystemZ] Add CodeGen support for integer vector typesUlrich Weigand2015-05-051-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This the first of a series of patches to add CodeGen support exploiting the instructions of the z13 vector facility. This patch adds support for the native integer vector types (v16i8, v8i16, v4i32, v2i64). When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level (implemented in clang), but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236521
* Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"Sergey Dmitrouk2015-04-281-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | [DebugInfo] Add debug locations to constant SD nodes This adds debug location to constant nodes of Selection DAG and updates all places that create constants to pass debug locations (see PR13269). Can't guarantee that all locations are correct, but in a lot of cases choice is obvious, so most of them should be. At least all tests pass. Tests for these changes do not cover everything, instead just check it for SDNodes, ARM and AArch64 where it's easy to get incorrect locations on constants. This is not complete fix as FastISel contains workaround for wrong debug locations, which drops locations from instructions on processing constants, but there isn't currently a way to use debug locations from constants there as llvm::Constant doesn't cache it (yet). Although this is a bit different issue, not directly related to these changes. Differential Revision: http://reviews.llvm.org/D9084 llvm-svn: 235989
* Revert "[DebugInfo] Add debug locations to constant SD nodes"Daniel Jasper2015-04-281-22/+20
| | | | | | | This breaks a test: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/23870 llvm-svn: 235987
* [DebugInfo] Add debug locations to constant SD nodesSergey Dmitrouk2015-04-281-20/+22
| | | | | | | | | | | | | | | | | | | | | | | This adds debug location to constant nodes of Selection DAG and updates all places that create constants to pass debug locations (see PR13269). Can't guarantee that all locations are correct, but in a lot of cases choice is obvious, so most of them should be. At least all tests pass. Tests for these changes do not cover everything, instead just check it for SDNodes, ARM and AArch64 where it's easy to get incorrect locations on constants. This is not complete fix as FastISel contains workaround for wrong debug locations, which drops locations from instructions on processing constants, but there isn't currently a way to use debug locations from constants there as llvm::Constant doesn't cache it (yet). Although this is a bit different issue, not directly related to these changes. Differential Revision: http://reviews.llvm.org/D9084 llvm-svn: 235977
* [SystemZ] Support RISBGN instruction on zEC12Ulrich Weigand2015-03-311-2/+9
| | | | | | | | | | | | | | So far, we do not yet support any instruction specific to zEC12. Most of the facilities added with zEC12 are indeed not very useful to compiler code generation, but there is one exception: the miscellaneous-extensions facility provides the RISBGN instruction, which is a variant of RISBG that does not set the condition code. Add support for this facility, MC support for RISBGN, and CodeGen support for prefering RISBGN over RISBG on zEC12, unless we can actually make use of the condition code set by RISBG. llvm-svn: 233690
* [systemz] Distinguish the 'Q', 'R', 'S', and 'T' inline assembly memory ↵Daniel Sanders2015-03-171-13/+23
| | | | | | | | | | | | | | | | | | | | constraints. Summary: But still handle them the same way since I don't know how they differ on this target. No functional change intended. Reviewers: uweigand Reviewed By: uweigand Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8251 llvm-svn: 232495
* Recommit r232027 with PR22883 fixed: Add infrastructure for support of ↵Daniel Sanders2015-03-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | multiple memory constraints. The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. PR22883 was caused the matching operands copying the whole of the operand flags for the matched operand. This included the constraint id which needed to be replaced with the operand number. This has been fixed with a conversion function. Following on from this, matching operands also used the operand number as the constraint id. This has been fixed by looking up the matched operand and taking it from there. llvm-svn: 232165
* Revert "r232027 - Add infrastructure for support of multiple memory constraints"Hal Finkel2015-03-121-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | This (r232027) has caused PR22883; so it seems those bits might be used by something else after all. Reverting until we can figure out what else to do. Original commit message: The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. llvm-svn: 232093
* Add infrastructure for support of multiple memory constraints.Daniel Sanders2015-03-121-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: hfinkel, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D8171 llvm-svn: 232027
* Reuse a bunch of cached subtargets and remove getSubtarget callsEric Christopher2015-01-311-7/+9
| | | | | | without a Function argument. llvm-svn: 227647
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-4/+4
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-2/+2
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-3/+3
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-10/+10
| | | | llvm-svn: 207197
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* Break PseudoSourceValue out of the Value hierarchy. It is now the root of ↵Nick Lewycky2014-04-151-2/+2
| | | | | | its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead. llvm-svn: 206255
* [SystemZ] Remove "virtual" from override methodsRichard Sandiford2014-03-061-5/+4
| | | | | | | Also fix a couple of cases where "override" was missing. No behavioural change intended. llvm-svn: 203110
* [SystemZ] Use "auto" for cast resultsRichard Sandiford2014-03-061-20/+14
| | | | | | No functional change intended. llvm-svn: 203106
* Switch all uses of LLVM_OVERRIDE to just use 'override' directly.Craig Topper2014-03-021-6/+5
| | | | llvm-svn: 202621
* [SystemZ] Fix RNSBG bug introduced by r197802Richard Sandiford2014-01-091-8/+10
| | | | | | | | The zext handling added in r197802 wasn't right for RNSBG. This patch restricts it to ROSBG, RXSBG and RISBG. (The tests for RISBG were added in r197802 since RISBG was the motivating example.) llvm-svn: 198862
* [SystemZ] Use interlocked-access 1 instructions for CodeGenRichard Sandiford2013-12-241-14/+0
| | | | | | | | | ...namely LOAD AND ADD, LOAD AND AND, LOAD AND OR and LOAD AND EXCLUSIVE OR. LOAD AND ADD LOGICAL isn't really separately useful for LLVM. I'll look at adding reusing the CC results in new year. llvm-svn: 197985
* [SystemZ] Extend RISBG optimizationRichard Sandiford2013-12-201-3/+17
| | | | | | | | | | | | The handling of ANY_EXTEND and ZERO_EXTEND was too strict. In this context we can treat ZERO_EXTEND in much the same way as an AND and then also handle outermost ZERO_EXTENDs. I couldn't find a test that benefited from the ANY_EXTEND change, but it's more obvious to write it this way once SIGN_EXTEND and ZERO_EXTEND are handled differently. llvm-svn: 197802
* [SystemZ] Fix incorrect use of RISBG for a zero-extended right shiftRichard Sandiford2013-11-261-19/+8
| | | | | | | | | We would wrongly transform the testcase into the equivalent of an AND with 1. The problem was that, when testing whether the shifted-in bits of the right shift were significant, we used the width of the final zero-extended result rather than the width of the shifted value. llvm-svn: 195731
* [SystemZ] Handle extensions in RxSBG optimizationsRichard Sandiford2013-10-161-8/+26
| | | | | | | The input to an RxSBG operation can be narrower as long as the upper bits are don't care. This fixes a FIXME added in r192783. llvm-svn: 192790
* [SystemZ] Extend 32-bit RISBG optimizations to high wordsRichard Sandiford2013-10-011-8/+16
| | | | | | | This involves using RISB[LH]G, whereas the equivalent z10 optimization uses RISBG. llvm-svn: 191770
* [SystemZ] Rename subregs and add subreg_h32Richard Sandiford2013-09-301-2/+2
| | | | | | | | | | | | | Use subreg_hNN and subreg_lNN for the high and low NN bits of a register. List the low registers first, so that subreg_l32 also means the low 32 bits of a 128-bit register. Floats are stored in the upper 32 bits of a 64-bit register, so they should use subreg_h32 rather than subreg_l32. No behavioral change intended. llvm-svn: 191659
* [SystemZ] Rein back the use of block operationsRichard Sandiford2013-09-271-18/+20
| | | | | | | | | | | | | | The backend tries to use block operations like MVC, NC, OC and XC for simple scalar operations. For correctness reasons, it rejects any case in which the regions might partially overlap. However, for performance reasons, it should also reject cases where the regions might be equal, since the instruction might then not use the fast path. This fixes a performance regression seen in bzip2. We may want to limit the optimisation even more in future, or even remove it entirely, but I'll try with this for now. llvm-svn: 191525
* [SystemZ] Improve handling of PC-relative addressesRichard Sandiford2013-09-271-48/+61
| | | | | | | | | | | | | | The backend previously folded offsets into PC-relative addresses whereever possible. That's the right thing to do when the address can be used directly in a PC-relative memory reference (using things like LRL). But if we have a register-based memory reference and need to load the PC-relative address separately, it's better to use an anchor point that could be shared with other accesses to the same area of the variable. Fixes a FIXME. llvm-svn: 191524
* ISelDAG: spot chain cycles involving MachineNodesTim Northover2013-09-221-0/+1
| | | | | | | | | | | | | | | | | Previously, the DAGISel function WalkChainUsers was spotting that it had entered already-selected territory by whether a node was a MachineNode (amongst other things). Since it's fairly common practice to insert MachineNodes during ISelLowering, this was not the correct check. Looking around, it seems that other nodes get their NodeId set to -1 upon selection, so this makes sure the same thing happens to all MachineNodes and uses that characteristic to determine whether we should stop looking for a loop during selection. This should fix PR15840. llvm-svn: 191165
* [SystemZ] Use getTarget{Insert,Extract}Subreg rather than getMachineNodeRichard Sandiford2013-09-131-12/+5
| | | | | | Just a clean-up, no behavioral change intended. llvm-svn: 190673
* [SystemZ] Add NC, OC and XCRichard Sandiford2013-09-051-19/+50
| | | | | | | For now these are just used to handle scalar ANDs, ORs and XORs in which all operands are memory. llvm-svn: 190041
* [SystemZ] Prefer LHI;ST... over LAY;MV...Richard Sandiford2013-08-231-0/+25
| | | | | | | | | | | | | | | | | | | If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. llvm-svn: 189098
* [SystemZ] Be more careful about inverting CC masks (conditional loads)Richard Sandiford2013-07-311-0/+21
| | | | | | | | Extend r187495 to conditional loads. I split this out because the easiest way seemed to be to force a particular operand order in SystemZISelDAGToDAG.cpp. llvm-svn: 187496
* [SystemZ] Postpone NI->RISBG conversion to convertToThreeAddress()Richard Sandiford2013-07-311-52/+41
| | | | | | | | | | | | | | | | | | | | | | r186399 aggressively used the RISBG instruction for immediate ANDs, both because it can handle some values that AND IMMEDIATE can't, and because it allows the destination register to be different from the source. I realized later while implementing the distinct-ops support that it would be better to leave the choice up to convertToThreeAddress() instead. The AND IMMEDIATE form is shorter and is less likely to be cracked. This is a problem for 32-bit ANDs because we assume that all 32-bit operations will leave the high word untouched, whereas RISBG used in this way will either clear the high word or copy it from the source register. The patch uses the z196 instruction RISBLG for this instead. This means that z10 will be restricted to NILL, NILH and NILF for 32-bit ANDs, but I think that should be OK for now. Although we're using z10 as the base architecture, the optimization work is going to be focused more on z196 and zEC12. llvm-svn: 187492
* [SystemZ] Use RNSBGRichard Sandiford2013-07-181-16/+67
| | | | | | This should be the last of the R.SBG patches for now. llvm-svn: 186573
* [SystemZ] Generalize RxSBG SRA caseRichard Sandiford2013-07-181-27/+36
| | | | | | | | | The original code only folded SRA into ROTATE ... SELECTED BITS if there was no outer shift. This patch splits out that check and generalises it slightly. The extra cases aren't really that interesting, but this is paving the way for RNSBG support. llvm-svn: 186571
* [SystemZ] Use RXSBGRichard Sandiford2013-07-181-11/+16
| | | | | | Extend the previous R.SBG patches to handle XORs. llvm-svn: 186570
* [SystemZ] Rename and formatting fixesRichard Sandiford2013-07-181-64/+61
| | | | | | | | | | | | In hindsight, using "RISBG" for something that can be any type of R.SBG instruction was a bit confusing, so this renames it to RxSBG. That might not be the best choice either, since there is an instruction called RXSBG, but hopefully the lower-case letter stands out enough. While there I fixed a couple of GNUisms that had crept in -- sorry about that! llvm-svn: 186569
OpenPOWER on IntegriCloud