summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Don't print 'dword ptr' or 'qword ptr' on the operand to some of the ↵Craig Topper2015-01-081-1/+2
| | | | | | LEA variants in Intel syntax. The memory operand is inherently unsized. llvm-svn: 225432
* [X86] Remove some unused TYPE enums from the disassembler.Craig Topper2015-01-071-1/+0
| | | | llvm-svn: 225343
* [X86] Add OpSize32 to XBEGIN_4. Add XBEGIN_2 with OpSize16.Craig Topper2015-01-061-2/+4
| | | | | | Requires new AsmParserOperand types that detect 16-bit and 32/64-bit mode so that we choose the right instruction based on default sizing without predicates. This is necessary since predicates mess up the disassembler table building. llvm-svn: 225256
* [X86] Remove unused operand type from disassembler handling. NFCCraig Topper2015-01-051-1/+0
| | | | llvm-svn: 225151
* Fix some formatting in tablegen output.Craig Topper2015-01-031-7/+4
| | | | llvm-svn: 225113
* Replace some 'unreachable' comments with llvm_unreachable.Craig Topper2015-01-031-2/+2
| | | | llvm-svn: 225112
* [X86] Disassembler support for move to/from %rax with a 32-bit memory offset ↵Craig Topper2015-01-032-2/+12
| | | | | | is REX.W and AdSize prefix are both present. llvm-svn: 225099
* [X86] Make the instructions that use AdSize16/32/64 co-exist together ↵Craig Topper2015-01-023-19/+44
| | | | | | | | | | without using mode predicates. This is necessary to allow the disassembler to be able to handle AdSize32 instructions in 64-bit mode when address size prefix is used. Eventually we should probably also support 'addr32' and 'addr16' in the assembler to override the address size on some of these instructions. But for now we'll just use special operand types that will lookup the current mode size to select the right instruction. llvm-svn: 225075
* [X86] Fix disassembly of absolute moves to work correctly in 16 and 32-bit ↵Craig Topper2014-12-312-14/+18
| | | | | | modes with all 4 combinations of OpSize and AdSize prefixes being present or not. llvm-svn: 225036
* Masked Load/Store - Changed the order of parameters in intrinsics.Elena Demikhovsky2014-12-252-2/+7
| | | | | | | No functional changes. The documentation is coming. llvm-svn: 224829
* [X86] Remove the single AdSize indicator and replace it with separate ↵Craig Topper2014-12-243-5/+12
| | | | | | | | AdSize16/32/64 flags. This removes a hardcoded list of instructions in the CodeEmitter. Eventually I intend to remove the predicates on the affected instructions since in any given mode two of them are valid if we supported addr32/addr16 prefixes in the assembler. llvm-svn: 224809
* Use iterators rather than indices to make this forwards-compatible with a ↵David Blaikie2014-12-221-4/+5
| | | | | | change to the underlying container (to std::list) llvm-svn: 224734
* unique_ptrify MatchableInfo(const CodeGenInstAlias *Alias)'s parameterDavid Blaikie2014-12-221-14/+11
| | | | llvm-svn: 224733
* On behalf of Matthew Wahab:Evgeny Astigeevich2014-12-161-1/+7
| | | | | | | | | | | | | | | | An instruction alias defined with InstAlias and an optional operand in the middle of the AsmString field, "..${a} <operands>", would get the final "}" printed in the instruction disassembly. This wouldn't happen if the optional operand appeared as the last item in the AsmString which is how the current backends avoided the problem. There don't appear to be any tests for this part of Tablegen but it passes the pre-commit tests. Manually tested the change by enabling the generic alias printer in the ARM backend and checking the output. Differential Revision: http://reviews.llvm.org/D6529 llvm-svn: 224348
* [MC] Reset the MCInst in the matcher function before adding opcode/operands.Ahmed Bougacha2014-12-161-0/+1
| | | | | | | | | | | | | | | | | | On X86, the Intel asm parser tries to match all memory operand sizes when none is explicitly specified. For LEA, which doesn't really have a memory operand (just a pointer one), this results in multiple successful matches, one for each memory size. There's no error because it's same opcode, so really, it's just one match. However, the tablegen'd matcher function adds opcode/operands to the passed MCInst, and this results in multiple duplicated operands. This commit clears the MCInst in the tablegen'd matcher function. We sometimes clear it when the match failed, so there's no expectation of keeping the previous content anyway. Differential Revision: http://reviews.llvm.org/D6670 llvm-svn: 224347
* Use unique_ptr to remove explicit delete.Craig Topper2014-12-153-9/+9
| | | | llvm-svn: 224224
* Use range-based for loops.Craig Topper2014-12-131-52/+35
| | | | llvm-svn: 224187
* Clean up static analyzer warnings.Michael Ilseman2014-12-123-2/+5
| | | | | | | | | Clang's static analyzer found several potential cases of undefined behavior, use of un-initialized values, and potentially null pointer dereferences in tablegen, Support, MC, and ADT. This cleans them up with specific assertions on the assumptions of the code. llvm-svn: 224154
* Try to include operand counts for mismatches in tablegen.Matt Arsenault2014-12-111-6/+21
| | | | llvm-svn: 224068
* Use range-based for loops. NFCCraig Topper2014-12-111-9/+7
| | | | llvm-svn: 224005
* Use unique_ptr instead of DeleteContainerSeconds.Craig Topper2014-12-102-12/+12
| | | | llvm-svn: 223918
* Tablegen'erate lanemasks for register units.Matthias Braun2014-12-103-6/+86
| | | | | | Now we can relate lanemasks in a virtual register to register units. llvm-svn: 223889
* Add function that translates subregister lane masks to other subregs.Matthias Braun2014-12-103-1/+175
| | | | | | | This works like the composeSubRegisterIndices() function but transforms a subregister lane mask instead of a subregister index. llvm-svn: 223874
* Let tablegen compute maximum lanemask for regs/regclasses.Matthias Braun2014-12-103-5/+20
| | | | | | | | Let tablegen compute the combination of subregister lanemasks for all subregisters in a register/register class. This is preparation for further work subregister allocation llvm-svn: 223873
* Use range-based for loops. NFC.Craig Topper2014-12-092-35/+24
| | | | llvm-svn: 223762
* Masked Load / Store Intrinsics - the CodeGen part.Elena Demikhovsky2014-12-042-2/+11
| | | | | | | | | | | | | | | | | | I'm recommiting the codegen part of the patch. The vectorizer part will be send to review again. Masked Vector Load and Store Intrinsics. Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores. Added SDNodes for masked operations and lowering patterns for X86 code generator. Examples: <16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask) declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask) Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch. http://reviews.llvm.org/D6191 llvm-svn: 223348
* range-for some thingsDavid Blaikie2014-12-031-19/+12
| | | | llvm-svn: 223263
* Simplify CodeGenRegBank::inferMatchingSuperRegClass & its caller by passing ↵David Blaikie2014-12-032-18/+23
| | | | | | an iterator rather than index llvm-svn: 223262
* Simplify ownership of RegClasses by using list<CodeGenRegisterClass> instead ↵David Blaikie2014-12-036-110/+100
| | | | | | | | | | of vector<CodeGenRegisterClass*> This complicates a few algorithms due to not having random access, but not by a huge degree I don't think (open to debate/design discussion/etc). llvm-svn: 223261
* Range-for some stuff related to RegClasses, and comment cases where ↵David Blaikie2014-12-036-124/+124
| | | | | | range-for isn't suitable. llvm-svn: 223260
* [Statepoints 2/4] Statepoint infrastructure for garbage collection: MI & ↵Philip Reames2014-12-011-0/+1
| | | | | | | | | | | | | | x86-64 Backend This is the second patch in a small series. This patch contains the MachineInstruction and x86-64 backend pieces required to lower Statepoints. It does not include the code to actually generate the STATEPOINT machine instruction and as a result, the entire patch is currently dead code. I will be submitting the SelectionDAG parts within the next 24-48 hours. Since those pieces are by far the most complicated, I wanted to minimize the size of that patch. That patch will include the tests which exercise the functionality in this patch. The entire series can be seen as one combined whole in http://reviews.llvm.org/D5683. The STATEPOINT psuedo node is generated after all gc values are explicitly spilled to stack slots. The purpose of this node is to wrap an actual call instruction while recording the spill locations of the meta arguments used for garbage collection and other purposes. The STATEPOINT is modeled as modifing all of those locations to prevent backend optimizations from forwarding the value from before the STATEPOINT to after the STATEPOINT. (Doing so would break relocation semantics for collectors which wish to relocate roots.) The implementation of STATEPOINT is closely modeled on PATCHPOINT. Eventually, much of the code in this patch will be removed. The long term plan is to merge the functionality provided by statepoints and patchpoints. Merging their implementations in the backend is likely to be a good starting point. Reviewed by: atrick, ributzka llvm-svn: 223085
* Remove some unnecessary vector::reserve/assign calls.David Blaikie2014-11-291-9/+5
| | | | llvm-svn: 222959
* Remove indirection of vector<T*> in favor of deque<T>David Blaikie2014-11-295-112/+101
| | | | llvm-svn: 222958
* Use deque<T> rather than vector<T*> since it provides the same invalidation ↵David Blaikie2014-11-293-47/+38
| | | | | | | | | | | | | | | semantics (at least when removal is not needed) without the extra indirection/ownership complexity Order matters for this container, it seems (using a forward_list and replacing the original push_backs with emplace_fronts caused test failures). I didn't look too deeply into why. (& in retrospect, I might go back & change some of the forward_lists I introduced to deques anyway - since most don't require removal, deque is a more memory-friendly data structure (moderate locality while not invalidating pointers)) llvm-svn: 222950
* Constify some things in preparation for CodeGenSubRegIndex to be stored by ↵David Blaikie2014-11-293-86/+87
| | | | | | value in their container, removing the indirection llvm-svn: 222949
* Revert "Simplify some more ownership using forward_list<T> rather than ↵Duncan P. N. Exon Smith2014-11-281-66/+82
| | | | | | | | | | | | vector<unique_ptr<T>>" This reverts commit r222935 and its follow-up r222938 ("Push unique_ptr a bit further through some APIs and simplify some cleanup"), since it causes bot failures (at least on Darwin): http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/1391/ llvm-svn: 222943
* Reapply "Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>""David Blaikie2014-11-281-16/+14
| | | | | | | | | Just avoid using std::map::emplace since it's not implemented in libstdc++ 4.7. Reapplies r222937, reverted in r222939. llvm-svn: 222940
* Revert "Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>"David Blaikie2014-11-281-15/+16
| | | | | | | | | Seems libstdc++ on some buildbots is lacking std::map::emplace, which is weird... reverting while I look into it. This reverts commit r222937. llvm-svn: 222939
* Push unique_ptr a bit further through some APIs and simplify some cleanupDavid Blaikie2014-11-281-18/+13
| | | | llvm-svn: 222938
* Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>David Blaikie2014-11-281-16/+15
| | | | | | | | | | | Pointers and references to map elements are never invalidated (except on removal, which isn't used here) so there's no need for the indirection unless there's polymorphism at work. A little const correctness had to be fixed, since the indirection allowed some benign const violations. llvm-svn: 222937
* Revert "Masked Vector Load and Store Intrinsics."Duncan P. N. Exon Smith2014-11-282-11/+2
| | | | | | | | | | | This reverts commit r222632 (and follow-up r222636), which caused a host of LNT failures on an internal bot. I'll respond to the commit on the list with a reproduction of one of the failures. Conflicts: lib/Target/X86/X86TargetTransformInfo.cpp llvm-svn: 222936
* Simplify some more ownership using forward_list<T> rather than ↵David Blaikie2014-11-281-65/+54
| | | | | | vector<unique_ptr<T>> llvm-svn: 222935
* Forgotten formatting from previous commitDavid Blaikie2014-11-281-2/+2
| | | | llvm-svn: 222934
* Simplify ownership by using forward_list<T> rather than vector<unique_ptr<T>>David Blaikie2014-11-281-42/+42
| | | | | | | | Since the elements were not polymorphic, the unique_ptr was only used to avoid pointer invalidation on container resizes - might as well skip the indirection and use a container with suitable invalidation semantics. llvm-svn: 222931
* Fix a few memory leaks in CodeGenRegBank.Craig Topper2014-11-282-0/+7
| | | | llvm-svn: 222930
* Use unique_ptr to simplify deletion.Craig Topper2014-11-282-7/+5
| | | | llvm-svn: 222929
* Fix another memory leak in TableGen AsmMatcher by deleting CodeGenInstAliases.Craig Topper2014-11-281-0/+5
| | | | llvm-svn: 222912
* Use unique_ptr to fix some memory leaks in Tablegen AsmMatcherEmitter.Craig Topper2014-11-281-37/+44
| | | | llvm-svn: 222909
* Use range-based for loops and const-correct a few things.Craig Topper2014-11-281-59/+40
| | | | llvm-svn: 222908
* Remove neverHasSideEffects support from TableGen CodeGenInstruction. ↵Craig Topper2014-11-263-12/+0
| | | | | | Everyone should use hasSideEffects now. llvm-svn: 222809
OpenPOWER on IntegriCloud