summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Sparc/SparcISelDAGToDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [SelectionDAG] Disallow indirect "i" constraintFangrui Song2019-12-291-1/+0
| | | | | | | | | This allows us to delete InlineAsm::Constraint_i workarounds in SelectionDAGISel::SelectInlineAsmMemoryOperand overrides and TargetLowering::getInlineAsmMemConstraint overrides. They were introduced to X86 in r237517 to prevent crashes for constraints like "=*imr". They were later copied to other targets.
* Sparc - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-131-1/+1
|
* Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders2019-08-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
* Implementation of asm-goto support in LLVMCraig Topper2019-02-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Revert "This pass, fixing an erratum in some LEON 2 processors..."Daniel Cederman2018-04-201-6/+0
| | | | | | | | | | | | | | | | | | | | | Summary: Reading Atmel's AT697E errata document this does not seem like a valid workaround. While the text only mentions SDIV, it says that the ICC flags can be wrong, and those are only generated by SDIVcc. Verification on hardware shows that simply replacing SDIV with SDIVcc does not avoid the bug with negative operands. This reverts r283727. Reviewers: lero_chris, jyknight Reviewed By: jyknight Subscribers: fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D45813 llvm-svn: 330397
* [Sparc] Fix addressing mode when using 64-bit values in inline assemblyDaniel Cederman2018-04-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a 64-bit register is used as an operand in inline assembly together with a memory reference, the memory addressing will be wrong. The addressing will be a single reg, instead of reg+reg or reg+imm. This will generate a bad offset value or an exception in printMemOperand(). For example: ``` long long int val = 5; long long int mem; __asm__ volatile ("std %1, %0":"=m"(mem):"r"(val)); ``` becomes: ``` std %i0, [%i2+589833] ``` The problem is that SelectInlineAsmMemoryOperand() is never called for the memory references if one of the operands is a 64-bit register. By calling SelectInlineAsmMemoryOperands() in tryInlineAsm() the Sparc version of SelectInlineAsmMemoryOperand() gets called for each memory reference. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: eraman, fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D45761 llvm-svn: 330392
* This pass, fixing an erratum in some LEON 2 processors ensures that the SDIV ↵Chris Dewhurst2016-10-101-0/+6
| | | | | | | | instruction is not issued, but replaced by SDIVcc instead, which does not exhibit the error. Unit test included. Differential Review: https://reviews.llvm.org/D24660 llvm-svn: 283727
* [Sparc] Implement UMUL_LOHI and SMUL_LOHI instead of MULHS/MULHU/MUL.James Y Knight2016-10-051-13/+0
| | | | | | | This is what the instruction-set actually provides, and the default expansions of the others into the lohi opcodes are good. llvm-svn: 283381
* Use StringRef in Pass/PassManager APIs (NFC)Mehdi Amini2016-10-011-1/+1
| | | | llvm-svn: 283004
* [Sparc] Enable more inline assembly constraints.Chris Dewhurst2016-05-201-0/+1
| | | | | | | | Note: This is specifically to allow GCC's test pr44707 to pass. Trivial change, not put for differential revision. Test included. llvm-svn: 270192
* SDAG: Implement Select instead of SelectImpl in SparcDAGToDAGISelJustin Bogner2016-05-131-16/+17
| | | | | | | | | | | - 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. - Where we were calling SelectNodeTo, just return afterwards. Part of llvm.org/pr26808. llvm-svn: 269490
* SDAG: Clean up a dangling node in SparcISelDAGToDAG::SelectImplJustin Bogner2016-05-131-0/+1
| | | | | | | | | When we convert to the void Select interface, leaving unreferenced nodes around won't be allowed anymore. Part of llvm.org/pr26808. llvm-svn: 269396
* SDAG: Rename Select->SelectImpl and repurpose Select as returning voidJustin Bogner2016-05-051-2/+2
| | | | | | | | | | | | | | 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
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [Sparc] Implement i64 load/store support for 32-bit sparc.James Y Knight2015-08-101-0/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LDD/STD instructions can load/store a 64bit quantity from/to memory to/from a consecutive even/odd pair of (32-bit) registers. They are part of SparcV8, and also present in SparcV9. (Although deprecated there, as you can store 64bits in one register). As recommended on llvmdev in the thread "How to enable use of 64bit load/store for 32bit architecture" from Apr 2015, I've modeled the 64-bit load/store operations as working on a v2i32 type, rather than making i64 a legal type, but with few legal operations. The latter does not (currently) work, as there is much code in llvm which assumes that if i64 is legal, operations like "add" will actually work on it. The same assumption does not hold for v2i32 -- for vector types, it is workable to support only load/store, and expand everything else. This patch: - Adds a new register class, IntPair, for even/odd pairs of registers. - Modifies the list of reserved registers, the stack spilling code, and register copying code to support the IntPair register class. - Adds support in AsmParser. (note that in asm text, you write the name of the first register of the pair only. So the parser has to morph the single register into the equivalent paired register). - Adds the new instructions themselves (LDD/STD/LDDA/STDA). - Hooks up the instructions and registers as a vector type v2i32. Adds custom legalizer to transform i64 load/stores into v2i32 load/stores and bitcasts, so that the new instructions can actually be generated, and marks all operations other than load/store on v2i32 as needing to be expanded. - Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG. This hack undoes the transformation of i64 operands into two arbitrarily-allocated separate i32 registers in SelectionDAGBuilder. and instead passes them in a single IntPair. (Arbitrarily allocated registers are not useful, asm code expects to be receiving a pair, which can be passed to ldd/std.) Also adds a bunch of test cases covering all the bugs I've added along the way. Differential Revision: http://reviews.llvm.org/D8713 llvm-svn: 244484
* Make TargetLowering::getPointerTy() taking DataLayout as an argumentMehdi Amini2015-07-091-5/+8
| | | | | | | | | | | | | | | | Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, ted, yaron.keren, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D11028 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 241775
* [SPARC] Cleanup handling of the Y/ASR registers.James Y Knight2015-07-081-10/+8
| | | | | | | | | | | | | | | | | | - Implement copying ASR to/from GPR regs. - Mark ASRs as non-allocatable, so it won't try to arbitrarily use them inappropriately. - Instead of inserting explicit WRASR/RDASR nodes in the MUL/DIV routines, just do normal register copies. - Also...mark div as using Y, not just writing it. Added a test case with some code which previously died with an assertion failure (with -O0), or produced wrong code (otherwise). (Third time's the charm?) Differential Revision: http://reviews.llvm.org/D10401 llvm-svn: 241686
* Add support for the Sparc implementation-defined "ASR" registers.James Y Knight2015-05-181-3/+7
| | | | | | | | | | (Note that register "Y" is essentially just ASR0). Also added some test cases for divide and multiply, which had none before. Differential Revision: http://reviews.llvm.org/D8670 llvm-svn: 237580
* Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"Sergey Dmitrouk2015-04-281-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | [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-6/+4
| | | | | | | 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-4/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* [sparc] Small fix to r232719 to make 2007-12-17-InvokeAsm.ll pass on the ↵Daniel Sanders2015-03-191-0/+1
| | | | | | buildbot. llvm-svn: 232720
* Recommit r232027 with PR22883 fixed: Add infrastructure for support of ↵Daniel Sanders2015-03-131-4/+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/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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-4/+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-301-8/+7
| | | | | | without a Function argument. llvm-svn: 227644
* Cache TargetLowering on SelectionDAGISel and update previousEric Christopher2014-10-081-7/+5
| | | | | | calls to getTargetLowering() with the cached variable. llvm-svn: 219284
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-1/+2
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [C++11] Add 'override' keywords and remove 'virtual'. Additionally add ↵Craig Topper2014-04-291-5/+5
| | | | | | 'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. Sparc edition llvm-svn: 207502
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-1/+1
| | | | llvm-svn: 207197
* ISelDAG: spot chain cycles involving MachineNodesTim Northover2013-09-221-1/+3
| | | | | | | | | | | | | | | | | 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
* [Sparc] Add support for TLS in sparc.Venkatraman Govindaraju2013-09-221-2/+4
| | | | llvm-svn: 191164
* Access the TargetLoweringInfo from the TargetMachine object instead of ↵Bill Wendling2013-06-191-5/+7
| | | | | | caching it. The TLI may change between functions. No functionality change. llvm-svn: 184360
* Cache the TargetLowering info object as a pointer.Bill Wendling2013-06-061-4/+4
| | | | | | | Caching it as a pointer allows us to reset it if the TargetMachine object changes. llvm-svn: 183361
* Track IR ordering of SelectionDAG nodes 2/4.Andrew Trick2013-05-251-1/+1
| | | | | | | Change SelectionDAG::getXXXNode() interfaces as well as call sites of these functions to pass in SDLoc instead of DebugLoc. llvm-svn: 182703
* Add 64-bit multiply and divide instructions for SPARC v9.Jakob Stoklund Olesen2013-04-161-0/+3
| | | | llvm-svn: 179582
* Use the correct types when matching ADDRri patterns from frame indexes.Jakob Stoklund Olesen2013-04-131-3/+4
| | | | | | | It doesn't seem like anybody is checking types this late in isel, so no test case. llvm-svn: 179462
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Remove dead code. Improve llvm_unreachable text. Simplify some control flow.Ahmed Charles2012-02-191-1/+0
| | | | llvm-svn: 150918
* rename MVT::Flag to MVT::Glue. "Flag" is a terrible name forChris Lattner2010-12-211-2/+2
| | | | | | | something that just glues two nodes together, even if it is sometimes used for flags. llvm-svn: 122310
* fix a long standing wart: all the ComplexPattern's were beingChris Lattner2010-09-211-8/+6
| | | | | | | | | | | passed the root of the match, even though only a few patterns actually needed this (one in X86, several in ARM [which should be refactored anyway], and some in CellSPU that I don't feel like detangling). Instead of requiring all ComplexPatterns to take the dead root, have targets opt into getting the root by putting SDNPWantRoot on the ComplexPattern. llvm-svn: 114471
* Don't call Predicate_* methods directly from Sparc target.Jakob Stoklund Olesen2010-08-171-4/+4
| | | | | | | | | Modernize predicates a bit. The Predicate_* methods are not used by TableGen any longer. They are only emitted for the sake of legacy code. llvm-svn: 111263
* Delete an unnecessary reference to SelectionDAGISel::BB.Dan Gohman2010-04-191-1/+0
| | | | llvm-svn: 101824
* Use const qualifiers with TargetLowering. This eliminates severalDan Gohman2010-04-171-1/+0
| | | | | | | | | | | | | const_casts, and it reinforces the design of the Target classes being immutable. SelectionDAGISel::IsLegalToFold is now a static member function, because PIC16 uses it in an unconventional way. There is more room for API cleanup here. And PIC16's AsmPrinter no longer uses TargetLowering. llvm-svn: 101635
* Sink InstructionSelect() out of each target into SDISel, and rename itChris Lattner2010-03-021-15/+1
| | | | | | | | | | | | DoInstructionSelection. Inline "SelectRoot" into it from DAGISelHeader. Sink some other stuff out of DAGISelHeader into SDISel. Eliminate the various 'Indent' stuff from various targets, which dates to when isel was recursive. 17 files changed, 114 insertions(+), 430 deletions(-) llvm-svn: 97555
* Change SelectCode's argument from SDValue to SDNode *, to make it moreDan Gohman2010-01-051-10/+9
| | | | | | | | | clear what information these functions are actually using. This is also a micro-optimization, as passing a SDNode * around is simpler than passing a { SDNode *, int } by value or reference. llvm-svn: 92564
* Remove uninteresting and confusing debug output.Dan Gohman2009-11-051-1/+0
| | | | llvm-svn: 86149
* Rename getTargetNode to getMachineNode, for consistency with theDan Gohman2009-09-251-4/+4
| | | | | | | | naming scheme used in SelectionDAG, where there are multiple kinds of "target" nodes, but "machine" nodes are nodes which represent a MachineInstr. llvm-svn: 82790
OpenPOWER on IntegriCloud