summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove FIXME about asserting on the end iteratorReid Kleckner2016-08-111-5/+1
| | | | | | | | | After machine block placement, MBBs may not have terminators, and it is appropriate to check for the end iterator here. We can fold the check into the next if, as well. This look is really just looking for BBs that end in CATCHRET. llvm-svn: 278350
* CodeGen: Check for a terminator in llvm::getFuncletMembershipDuncan P. N. Exon Smith2016-08-111-0/+5
| | | | | | | | | | | | Check for an end iterator from MachineBasicBlock::getFirstTerminator in llvm::getFuncletMembership. If this is turned into an assertion, it fires in 48 X86 testcases (for example, CodeGen/X86/regalloc-spill-at-ehpad.ll). Since this is likely a latent bug (shouldn't all basic blocks end with a terminator?) I've filed PR28938. llvm-svn: 278344
* Avoid false dependencies of undef machine operandsMarina Yatsina2016-08-111-0/+53
| | | | | | | | | | | | | | | | | | | | This patch helps avoid false dependencies on undef registers by updating the machine instructions' undef operand to use a register that the instruction is truly dependent on, or use a register with clearance higher than Pref. Pseudo example: loop: xmm0 = ... xmm1 = vcvtsi2sdl eax, xmm0<undef> ... = inst xmm0 jmp loop In this example, selecting xmm0 as the undef register creates false dependency between loop iterations. This false dependency cannot be solved by inserting an xor before vcvtsi2sdl because xmm0 is alive at the point of the vcvtsi2sdl instruction. Selecting a different register instead of xmm0, especially a register that is not used in the loop, will eliminate this problem. Differential Revision: https://reviews.llvm.org/D22466 llvm-svn: 278321
* GlobalISel: support same ConstantExprs as Instructions.Tim Northover2016-08-101-75/+41
| | | | | | | | It's more than just inttoptr, but the others can't be tested until we have support for non-trivial constants (they currently get unavoidably folded to a ConstantInt). llvm-svn: 278303
* GlobalISel: implement simple function calls on AArch64.Tim Northover2016-08-101-4/+17
| | | | | | | We're still limited in the arguments we support, but this at least handles the basic cases. llvm-svn: 278293
* Codegen: Don't tail-duplicate blocks with un-analyzable fallthrough.Kyle Butt2016-08-101-0/+10
| | | | | | | | | | | | If AnalyzeBranch can't analyze a block and it is possible to fallthrough, then duplicating the block doesn't make sense, as only one block can be the layout predecessor for the un-analyzable fallthrough. Submitted wit a test case, but NOTE: the test case doesn't currently fail. However, the test case fails with D20505 and would have saved me some time debugging. llvm-svn: 278288
* CodeGen: If Convert blocks that would form a diamond when tail-merged.Kyle Butt2016-08-101-65/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following function currently relies on tail-merging for if conversion to succeed. The common tail of cond_true and cond_false is extracted, and this then forms a diamond pattern that can be successfully if converted. If this block does not get extracted, either because tail-merging is disabled or the threshold is higher, we should still recognize this pattern and if-convert it. Fixed a regression in the original commit. Need to un-reverse branches after reversing them, or other conversions go awry. define i32 @t2(i32 %a, i32 %b) nounwind { entry: %tmp1434 = icmp eq i32 %a, %b ; <i1> [#uses=1] br i1 %tmp1434, label %bb17, label %bb.outer bb.outer: ; preds = %cond_false, %entry %b_addr.021.0.ph = phi i32 [ %b, %entry ], [ %tmp10, %cond_false ] %a_addr.026.0.ph = phi i32 [ %a, %entry ], [ %a_addr.026.0, %cond_false ] br label %bb bb: ; preds = %cond_true, %bb.outer %indvar = phi i32 [ 0, %bb.outer ], [ %indvar.next, %cond_true ] %tmp. = sub i32 0, %b_addr.021.0.ph %tmp.40 = mul i32 %indvar, %tmp. %a_addr.026.0 = add i32 %tmp.40, %a_addr.026.0.ph %tmp3 = icmp sgt i32 %a_addr.026.0, %b_addr.021.0.ph br i1 %tmp3, label %cond_true, label %cond_false cond_true: ; preds = %bb %tmp7 = sub i32 %a_addr.026.0, %b_addr.021.0.ph %tmp1437 = icmp eq i32 %tmp7, %b_addr.021.0.ph %indvar.next = add i32 %indvar, 1 br i1 %tmp1437, label %bb17, label %bb cond_false: ; preds = %bb %tmp10 = sub i32 %b_addr.021.0.ph, %a_addr.026.0 %tmp14 = icmp eq i32 %a_addr.026.0, %tmp10 br i1 %tmp14, label %bb17, label %bb.outer bb17: ; preds = %cond_false, %cond_true, %entry %a_addr.026.1 = phi i32 [ %a, %entry ], [ %tmp7, %cond_true ], [ %a_addr.026.0, %cond_false ] ret i32 %a_addr.026.1 } Without tail-merging or diamond-tail if conversion: LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ble LBB1_3 @ BB#2: @ %cond_true @ in Loop: Header=BB1_1 Depth=1 subs r0, r0, r1 cmp r1, r0 it ne cmpne r0, r1 bgt LBB1_4 LBB1_3: @ %cond_false @ in Loop: Header=BB1_1 Depth=1 subs r1, r1, r0 cmp r1, r0 bne LBB1_1 LBB1_4: @ %bb17 bx lr With diamond-tail if conversion, but without tail-merging: @ BB#0: @ %entry cmp r0, r1 it eq bxeq lr LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ite le suble r1, r1, r0 subgt r0, r0, r1 cmp r1, r0 bne LBB1_1 @ BB#2: @ %bb17 bx lr llvm-svn: 278287
* LiveIntervalAnalysis: fix a crash in repairOldRegInRangeNicolai Haehnle2016-08-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See the new test case for one that was (non-deterministically) crashing on trunk and deterministically hit the assertion that I added in D23302. Basically, the machine function contains a sequence DS_WRITE_B32 %vreg4, %vreg14:sub0, ... DS_WRITE_B32 %vreg4, %vreg14:sub0, ... %vreg14:sub1<def> = COPY %vreg14:sub0 and SILoadStoreOptimizer::mergeWrite2Pair merges the two DS_WRITE_B32 instructions into one before calling repairIntervalsInRange. Now repairIntervalsInRange wants to repair %vreg14, in particular, and ends up trying to repair %vreg14:sub1 as well, but that only becomes active _after_ the range that is to be repaired, hence the crash due to LR.find(...) == LR.begin() at the start of repairOldRegInRange. I believe that just skipping those subrange is fine, but again, not too familiar with that code. Reviewers: MatzeB, kparzysz, tstellarAMD Subscribers: llvm-commits, MatzeB Differential Revision: https://reviews.llvm.org/D23303 llvm-svn: 278268
* Codegen: Tail Merge: Be less aggressive with special cases.Kyle Butt2016-08-101-4/+13
| | | | | | | | | | | | This change makes it possible for tail-duplication and tail-merging to be disjoint. By being less aggressive when merging during layout, there are no overlapping cases between tail-duplication and tail-merging, provided the thresholds are disjoint. There is a remaining TODO to benchmark the succ_size() test for non-layout tail merging. llvm-svn: 278265
* GlobalISel: avoid inserting redundant COPYs for bitcasts.Tim Northover2016-08-101-2/+5
| | | | | | | If the value produced by the bitcast hasn't been referenced yet, we can simply reuse the input register avoiding an unnecessary COPY instruction. llvm-svn: 278245
* [DAGCombine] Avoid INSERT_SUBVECTOR reinsertions (PR28678)Simon Pilgrim2016-08-101-1/+10
| | | | | | | | | | | If the input vector to INSERT_SUBVECTOR is another INSERT_SUBVECTOR, and this inserted subvector replaces the last insertion, then insert into the common source vector. i.e. INSERT_SUBVECTOR( INSERT_SUBVECTOR( Vec, SubOld, Idx ), SubNew, Idx ) --> INSERT_SUBVECTOR( Vec, SubNew, Idx ) Differential Revision: https://reviews.llvm.org/D23330 llvm-svn: 278211
* GlobalISel: support 'undef' constant.Tim Northover2016-08-091-4/+6
| | | | llvm-svn: 278174
* GlobalISel: first translation support for Constants.Tim Northover2016-08-091-1/+23
| | | | | | | | | For now put them all in the entry block. This should be correct but may give poor runtime performance. Hopefully MachineSinking combined with isReMaterializable can solve those issues, but if not the interface is sound enough to support alternatives. llvm-svn: 278168
* [DAGCombiner] Better support for shifting large value type by constantsSimon Pilgrim2016-08-091-17/+42
| | | | | | | | | | As detailed on D22726, much of the shift combining code assume constant values will fit into a uint64_t value and calls ConstantSDNode::getZExtValue where it probably shouldn't (leading to asserts). Using APInt directly avoids this problem but we encounter other assertions if we attempt to compare/operate on 2 APInt of different bitwidths. This patch adds a helper function to ensure that 2 APInt values are zero extended as required so that they can be safely used together. I've only added an initial example use for this to the '(SHIFT (SHIFT x, c1), c2) --> (SHIFT x, (ADD c1, c2))' combines. Further cases can easily be added as required. Differential Revision: https://reviews.llvm.org/D23007 llvm-svn: 278141
* Revert "[X86] Support the "ms-hotpatch" attribute."Charles Davis2016-08-081-14/+16
| | | | | | | | This reverts commit r278048. Something changed between the last time I built this--it takes awhile on my ridiculously slow and ancient computer--and now that broke this. llvm-svn: 278053
* [X86] Support the "ms-hotpatch" attribute.Charles Davis2016-08-081-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Based on two patches by Michael Mueller. This is a target attribute that causes a function marked with it to be emitted as "hotpatchable". This particular mechanism was originally devised by Microsoft for patching their binaries (which they are constantly updating to stay ahead of crackers, script kiddies, and other ne'er-do-wells on the Internet), but is now commonly abused by Windows programs to hook API functions. This mechanism is target-specific. For x86, a two-byte no-op instruction is emitted at the function's entry point; the entry point must be immediately preceded by 64 (32-bit) or 128 (64-bit) bytes of padding. This padding is where the patch code is written. The two byte no-op is then overwritten with a short jump into this code. The no-op is usually a `movl %edi, %edi` instruction; this is used as a magic value indicating that this is a hotpatchable function. Reviewers: majnemer, sanjoy, rnk Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D19908 llvm-svn: 278048
* [SelectionDAG] Refactor visitInlineAsm a bit. NFCI.Diana Picus2016-08-081-151/+198
| | | | | | This shaves off ~100 lines from visitInlineAsm. llvm-svn: 277987
* [MC] Delete use of *structors_used.Davide Italiano2016-08-081-12/+0
| | | | | | | Jim Grosbach and Kevin Enderby think those are not used anymore. Originally submitted by: Rafael Espindola llvm-svn: 277973
* Revert r277905, it caused PR28894Nico Weber2016-08-071-345/+66
| | | | llvm-svn: 277962
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-066-11/+11
| | | | llvm-svn: 277916
* [CodeGen] Fix a -Wdocumentation warningDavid Majnemer2016-08-061-1/+1
| | | | | | | A parameter was documented with the wrong name. No functionality change is intended. llvm-svn: 277915
* CodeGen: If Convert blocks that would form a diamond when tail-merged.Kyle Butt2016-08-061-66/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following function currently relies on tail-merging for if conversion to succeed. The common tail of cond_true and cond_false is extracted, and this then forms a diamond pattern that can be successfully if converted. If this block does not get extracted, either because tail-merging is disabled or the threshold is higher, we should still recognize this pattern and if-convert it. define i32 @t2(i32 %a, i32 %b) nounwind { entry: %tmp1434 = icmp eq i32 %a, %b ; <i1> [#uses=1] br i1 %tmp1434, label %bb17, label %bb.outer bb.outer: ; preds = %cond_false, %entry %b_addr.021.0.ph = phi i32 [ %b, %entry ], [ %tmp10, %cond_false ] %a_addr.026.0.ph = phi i32 [ %a, %entry ], [ %a_addr.026.0, %cond_false ] br label %bb bb: ; preds = %cond_true, %bb.outer %indvar = phi i32 [ 0, %bb.outer ], [ %indvar.next, %cond_true ] %tmp. = sub i32 0, %b_addr.021.0.ph %tmp.40 = mul i32 %indvar, %tmp. %a_addr.026.0 = add i32 %tmp.40, %a_addr.026.0.ph %tmp3 = icmp sgt i32 %a_addr.026.0, %b_addr.021.0.ph br i1 %tmp3, label %cond_true, label %cond_false cond_true: ; preds = %bb %tmp7 = sub i32 %a_addr.026.0, %b_addr.021.0.ph %tmp1437 = icmp eq i32 %tmp7, %b_addr.021.0.ph %indvar.next = add i32 %indvar, 1 br i1 %tmp1437, label %bb17, label %bb cond_false: ; preds = %bb %tmp10 = sub i32 %b_addr.021.0.ph, %a_addr.026.0 %tmp14 = icmp eq i32 %a_addr.026.0, %tmp10 br i1 %tmp14, label %bb17, label %bb.outer bb17: ; preds = %cond_false, %cond_true, %entry %a_addr.026.1 = phi i32 [ %a, %entry ], [ %tmp7, %cond_true ], [ %a_addr.026.0, %cond_false ] ret i32 %a_addr.026.1 } Without tail-merging or diamond-tail if conversion: LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ble LBB1_3 @ BB#2: @ %cond_true @ in Loop: Header=BB1_1 Depth=1 subs r0, r0, r1 cmp r1, r0 it ne cmpne r0, r1 bgt LBB1_4 LBB1_3: @ %cond_false @ in Loop: Header=BB1_1 Depth=1 subs r1, r1, r0 cmp r1, r0 bne LBB1_1 LBB1_4: @ %bb17 bx lr With diamond-tail if conversion, but without tail-merging: @ BB#0: @ %entry cmp r0, r1 it eq bxeq lr LBB1_1: @ %bb @ =>This Inner Loop Header: Depth=1 cmp r0, r1 ite le suble r1, r1, r0 subgt r0, r0, r1 cmp r1, r0 bne LBB1_1 @ BB#2: @ %bb17 bx lr llvm-svn: 277905
* IfConverter: Split ScanInstructions into 2 functions.Kyle Butt2016-08-061-13/+27
| | | | | | | | | | ScanInstructions is now 2 functions: AnalyzeBranches and ScanInstructions. ScanInstructions also now takes a pair of arguments delimiting the instructions to be scanned. This will be used for forked diamond support to re-scan only a portion of the block. llvm-svn: 277904
* IfConversion: Document countDuplicatedInstructions. NFCKyle Butt2016-08-061-0/+12
| | | | llvm-svn: 277903
* IfConversion: factor out 2 functions to skip debug instrs. NFCKyle Butt2016-08-061-24/+32
| | | | | | Skipping debug instructions occurrs repeatedly, factor it out. llvm-svn: 277902
* [CodeView] Decouple record deserialization from visitor dispatch.Zachary Turner2016-08-051-36/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, our use case for the visitor has been to take a stream of bytes representing a type stream, deserialize the records in sequence, and do something with them, where "something" is determined by how the user implements a particular set of callbacks on an abstract class. For actually writing PDBs, however, we want to do the reverse. We have some kind of description of the list of records in their in-memory format, and we want to process each one. Perhaps by serializing them to a byte stream, or perhaps by converting them from one description format (Yaml) to another (in-memory representation). This was difficult in the current model because deserialization and invoking the callbacks were tightly coupled. With this patch we change this so that TypeDeserializer is itself an implementation of the particular set of callbacks. This decouples deserialization from the iteration over a list of records and invocation of the callbacks. TypeDeserializer is initialized with another implementation of the callback interface, so that upon deserialization it can pass the deserialized record through to the next set of callbacks. In a sense this is like an implementation of the Decorator design pattern, where the Deserializer is a decorator. This will be useful for writing Pdbs from yaml, where we have a description of the type records in Yaml format. In this case, the visitor implementation would have each visitation callback method implemented in such a way as to extract the proper set of fields from the Yaml, and it could maintain state that builds up a list of these records. Finally at the end we can pass this information through to another set of callbacks which serializes them into a byte stream. Reviewed By: majnemer, ruiu, rnk Differential Revision: https://reviews.llvm.org/D23177 llvm-svn: 277871
* GlobalISel: clear pending phis after MachineFunction translatedTim Northover2016-08-051-0/+4
| | | | | | | Test is just reordering the existing functions (it would trigger for any function after one with a phi). llvm-svn: 277841
* GlobalISel: IRTranslate PHI instructionsTim Northover2016-08-051-0/+31
| | | | llvm-svn: 277835
* Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-08-052-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a registry" This differs from the previous version by being more careful about template instantiation/specialization in order to prevent errors when building with clang -Werror. Specifically: * begin is not defined in the template and is instead instantiated when Head is. I think the warning when we don't do that is wrong (PR28815) but for now at least do it this way to avoid the warning. * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY instead provide a template definition then do explicit instantiation. No compiler I've tried has problems with doing it the other way, but strictly speaking it's not permitted by the C++ standard so better safe than sorry. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 277806
* GlobalISel: extend add widening to SUB, MUL, OR, AND and XOR.Tim Northover2016-08-041-2/+8
| | | | | | | These are the operations that are trivially identical. Division is omitted for now because you need to use the correct sign/zero extension. llvm-svn: 277775
* GlobalISel: add support for G_MULTim Northover2016-08-041-0/+2
| | | | llvm-svn: 277774
* GlobalISel: implement narrowing for G_ADD.Tim Northover2016-08-042-1/+49
| | | | llvm-svn: 277769
* GlobalISel: also add G_TRUNC to IRTranslator.Tim Northover2016-08-041-1/+3
| | | | llvm-svn: 277749
* GlobalISel: add code to widen scalar G_ADDTim Northover2016-08-043-1/+39
| | | | llvm-svn: 277747
* [X86] Heuristic to selectively build Newton-Raphson SQRT estimationNikolai Bozhenov2016-08-042-3/+6
| | | | | | | | | | | | | | | | | | | | | On modern Intel processors hardware SQRT in many cases is faster than RSQRT followed by Newton-Raphson refinement. The patch introduces a simple heuristic to choose between hardware SQRT instruction and Newton-Raphson software estimation. The patch treats scalars and vectors differently. The heuristic is that for scalars the compiler should optimize for latency while for vectors it should optimize for throughput. It is based on the assumption that throughput bound code is likely to be vectorized. Basically, the patch disables scalar NR for big cores and disables NR completely for Skylake. Firstly, scalar SQRT has shorter latency than NR code in big cores. Secondly, vector SQRT has been greatly improved in Skylake and has better throughput compared to NR. Differential Revision: https://reviews.llvm.org/D21379 llvm-svn: 277725
* Typo fix in comment. NFCDiana Picus2016-08-041-1/+1
| | | | llvm-svn: 277704
* RenameIndependentSubregs: Fix liveness query in rewriteOperands()Matthias Braun2016-08-031-7/+6
| | | | | | | | rewriteOperands() always performed liveness queries at the base index rather than the RegSlot/Base as apropriate for the machine operand. This could lead to illegal rewriting in some cases. llvm-svn: 277661
* Disable shrinking of SNaN constantsElliot Colp2016-08-031-11/+17
| | | | | | | | | When expanding FP constants, we attempt to shrink doubles to floats and perform an extending load. However, on SystemZ, and possibly on other targets (I've only confirmed the problem on SystemZ), the FP extending load instruction may convert SNaN into QNaN, or may cause an exception. So in the general case, we would still like to shrink FP constants, but SNaNs should be left as doubles. Differential Revision: https://reviews.llvm.org/D22685 llvm-svn: 277602
* [IfConversion] Bugfix: Don't use undef flag while adding use operands.Jonas Paulsson2016-08-031-3/+16
| | | | | | | | | | | | | | | | | IfConversion used to always add the undef flag when adding a use operand on a newly predicated instruction. This would be an operand for the register being conditionally redefined. Due to the undef flag, the liveness of this register prior to the predicated instruction would get lost. This patch changes this so that such use operands are added only when the register is live, without the undef flag. This was reverted but pushed again now, for details follow link below. Reviewed by Quentin Colombet. http://reviews.llvm.org/D209077 llvm-svn: 277571
* [safestack] Layout large allocas first to reduce fragmentation.Evgeniy Stepanov2016-08-021-0/+8
| | | | llvm-svn: 277544
* [GlobalISel] Set the Selected MF property.Ahmed Bougacha2016-08-021-14/+0
| | | | | | | None of GlobalISel requires the property, but this lets us use the verifier instead of rolling our own "all instructions selected" check. llvm-svn: 277484
* [GlobalISel] Verify Selected MF property.Ahmed Bougacha2016-08-021-1/+15
| | | | | | | | After instruction selection, there should be no pre-isel generic instructions remaining, nor should generic virtual registers be used. Verify that. llvm-svn: 277483
* [GlobalISel] Add Selected MachineFunction property.Ahmed Bougacha2016-08-023-0/+7
| | | | | | | | | | | | | | | | Selected: the InstructionSelect pass ran and all pre-isel generic instructions have been eliminated; i.e., all instructions are now target-specific or non-pre-isel generic instructions (e.g., COPY). Since only pre-isel generic instructions can have generic virtual register operands, this also means that all generic virtual registers have been constrained to virtual registers (assigned to register classes) and that all sizes attached to them have been eliminated. This lets us enforce certain invariants across passes. This property is GlobalISel-specific, but is always available. llvm-svn: 277482
* [GlobalISel] Verify RegBankSelected MF property.Ahmed Bougacha2016-08-021-1/+17
| | | | | | | RegBankSelected functions shouldn't have any generic virtual register not assigned to a bank. Verify that. llvm-svn: 277476
* [GlobalISel] Add RegBankSelected MachineFunction property.Ahmed Bougacha2016-08-023-0/+8
| | | | | | | | | | RegBankSelected: the RegBankSelect pass ran and all generic virtual registers have been assigned to a register bank. This lets us enforce certain invariants across passes. This property is GlobalISel-specific, but is always available. llvm-svn: 277475
* [GlobalISel] Set, require, and verify Legalized MF property.Ahmed Bougacha2016-08-022-0/+35
| | | | | | | | | | | | | RegBankSelect and InstructionSelect run after the legalizer and require a Legalized function: check that all instructions are legal. Note that this should be in the MachineVerifier, but it can't use the MachineLegalizer as it's currently in the separate GlobalISel library. Note that the RegBankSelect verifier checks have the same layering problem, but we only use inline methods so end up not needing to link against the GlobalISel library. llvm-svn: 277472
* [GlobalISel] Add Legalized MachineFunction property.Ahmed Bougacha2016-08-023-0/+10
| | | | | | | | | | | | | Legalized: The MachineLegalizer ran; all pre-isel generic instructions have been legalized, i.e., all instructions are now one of: - generic and always legal (e.g., COPY) - target-specific - legal pre-isel generic instructions. This lets us enforce certain invariants across passes. This property is GlobalISel-specific, but is always available. llvm-svn: 277470
* [CodeGen] Generalize MachineFunctionProperties::print comma handling.Ahmed Bougacha2016-08-021-2/+7
| | | | | | | | This is only used for debug prints, but the previous hardcoded ", " caused it to be printed unnecessarily when OnlySet, and is annoying when adding new properties. llvm-svn: 277465
* [GlobalISel] Don't RegBankSelect target-specific instructions.Ahmed Bougacha2016-08-021-1/+7
| | | | | | They don't have types and should be using register classes. llvm-svn: 277447
* [GlobalISel] Don't legalize non-generic instructions.Ahmed Bougacha2016-08-021-0/+6
| | | | | | They don't have types and should be legal. llvm-svn: 277446
OpenPOWER on IntegriCloud