summaryrefslogtreecommitdiffstats
path: root/llvm/test
Commit message (Collapse)AuthorAgeFilesLines
* [AMDGPU] Allow SDWA in instructions with immediates and SGPRsStanislav Mekhanoshin2017-05-3048-216/+692
| | | | | | | | | | | | | | | | An encoding does not allow to use SDWA in an instruction with scalar operands, either literals or SGPRs. That is however possible to copy these operands into a VGPR first. Several copies of the value are produced if multiple SDWA conversions were done. To cleanup MachineLICM (to hoist copies out of loops), MachineCSE (to remove duplicate copies) and SIFoldOperands (to replace SGPR to VGPR copy with immediate copy right to the VGPR) runs are added after the SDWA pass. Differential Revision: https://reviews.llvm.org/D33583 llvm-svn: 304219
* [AMDGPU] Require waitcnt before barrier for all targets; adjust tests.Mark Searles2017-05-301-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D33576 llvm-svn: 304217
* This patch closes PR28513: an optimization of multiplication by different ↵Andrew V. Tischenko2017-05-303-360/+2982
| | | | | | | | constants. It's implemented on DAG combiner level. llvm-svn: 304209
* [SystemZ] Add decimal floating-point instructionsUlrich Weigand2017-05-3010-0/+3933
| | | | | | | | | This adds assembler / disassembler support for the decimal floating-point instructions. Since LLVM does not yet have support for decimal float types, these cannot be used for codegen at this point. llvm-svn: 304203
* [SystemZ] Add hexadecimal floating-point instructionsUlrich Weigand2017-05-303-1/+3513
| | | | | | | | This adds assembler / disassembler support for the hexadecimal floating-point instructions. Since the Linux ABI does not use any hex float data types, these are not useful for codegen. llvm-svn: 304202
* [SystemZ] Add missing assembler/disassembler testsUlrich Weigand2017-05-303-0/+148
| | | | | | | A few instructions that are actually correctly supported in the assembler and disassembler did not have any tests. llvm-svn: 304200
* [MC] Fix constant pools with DenseMap sentinel valuesOliver Stannard2017-05-301-0/+12
| | | | | | | | | | | | | The MC ConstantPool class uses a DenseMap to track generated constants, with the int64_t value of the constant as the key. This fails when values of 0x7fffffffffffffff or 0x7ffffffffffffffe are inserted into the constant pool, as these are sentinel values for DenseMap. The fix is to use std::map instead, which doesn't use sentinel values. Differential revision: https://reviews.llvm.org/D33667 llvm-svn: 304199
* [mips] Expansion of LI.S and LI.DZoran Jovanovic2017-05-302-0/+641
| | | | | | | | | Author: smaksimovic Reviewers: dsanders sdardis Introduces LI.S and LI.D pseudo instructions with floating point operands. Differential Revision: https://reviews.llvm.org/D14390 llvm-svn: 304198
* Fix PR33031: correct the estimate of maximum offset for instructions ↵Kristof Beyls2017-05-301-0/+52
| | | | | | spilling/filling the stack. llvm-svn: 304196
* Revert r303763, results in asserts i.e. while building Ruby.Joerg Sonnenberger2017-05-291-26/+0
| | | | llvm-svn: 304179
* [X86] Add tests for (ix bitcast (vxi1 and ...)). NFC.Zvi Rackover2017-05-292-0/+1558
| | | | | | To be improved by D33311. llvm-svn: 304171
* [X86] Replace undef value in flaky testZvi Rackover2017-05-291-3/+62
| | | | | | | D33311 exposes the flakiness in this test. Replacing the undef placed by bugpoint, makes it more interesting and robust. llvm-svn: 304168
* [wasm] Fix test after r304117.Benjamin Kramer2017-05-291-1/+1
| | | | llvm-svn: 304164
* [X86] Don't fold away the memory operand of an xchg.Benjamin Kramer2017-05-291-0/+37
| | | | | | | | | | xchg with a mem operand has different locking semantics. If we unfold it into a xchg r,r we will loose the implicit lock. Likewise we never want to fold a register xchg into a memory one as it would be a lot slower. This triggers during LLVM selfhost. llvm-svn: 304163
* [DAGCombiner] fix load narrowing transform to exclude loads with extensionSanjay Patel2017-05-291-0/+56
| | | | | | | | | | The extending load possibility was missed in: https://reviews.llvm.org/rL304072 We might want to handle this cases as a follow-up, but bailing out for now to avoid miscompiling. llvm-svn: 304153
* [Nios2] Target registrationNikolai Bozhenov2017-05-292-0/+14
| | | | | | | | | | | | | Reviewers: craig.topper, hfinkel, joerg, lattner, zvi Reviewed By: craig.topper Subscribers: oren_ben_simhon, igorb, belickim, tvvikram, mgorny, llvm-commits, pavel.v.chupin, DavidKreitzer Differential Revision: https://reviews.llvm.org/D32669 Patch by AndreiGrischenko <andrei.l.grischenko@intel.com> llvm-svn: 304144
* [ARM] GlobalISel: Support array returnsDiana Picus2017-05-291-24/+87
| | | | | | | These are a bit rare in practice, but they don't require anything special compared to array parameters, so support them as well. llvm-svn: 304137
* [ARM] GlobalISel: Support array parameters/argumentsDiana Picus2017-05-292-5/+298
| | | | | | | | | Clang coerces structs into arrays, so it's a good idea to support them. Most of the support boils down to getting the splitToValueTypes helper to actually split types. We then use G_INSERT/G_EXTRACT to deal with the parts. llvm-svn: 304132
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileMehdi Amini2017-05-291-0/+42
| | | | | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) Reapply of r304119 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304130
* DebugInfo: Omit an empty CU when a subprogram was moved into its useMehdi Amini2017-05-291-0/+54
| | | | | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. Reapply of r304111 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304129
* Revert "[IfConversion] Keep the CFG updated incrementally in IfConvertTriangle"Tobias Grosser2017-05-291-24/+0
| | | | | | | | | | | | | | | | | | The reverted change introdued assertions ala: "MachineBasicBlock::succ_iterator llvm::MachineBasicBlock::removeSuccessor(succ_iterator, bool): Assertion `I != Successors.end() && "Not a current successor!"' Mikael, the original committer, wrote me that he is working on a fix, but that it likely will take some time to get this resolved. As this bug is one of the last two issues that keep the AOSP buildbot from turning green, I revert the original commit r302876. I am looking forward to see this recommitted after the assertion has been resolved. llvm-svn: 304128
* Revert "DebugInfo: Omit an empty CU when a subprogram was moved into its use"Mehdi Amini2017-05-291-52/+0
| | | | | | | This reverts commit r304111. GreenDragon is broken. llvm-svn: 304126
* Revert "DebugInfo: Include .dwo file name when hashing multiple CUs in a ↵Mehdi Amini2017-05-292-40/+0
| | | | | | | | single file" This reverts commit r304119 and r304118. GreenDragon is broken. llvm-svn: 304125
* Resubmit "[X86] Adding new LLVM TableGen backend that generates the X86 ↵Zachary Turner2017-05-293-29/+16
| | | | | | | | | | | | | backend memory folding tables." This was reverted due to buildbot breakages and I was not familiar with this code to investigate it. But while trying to get a useful backtrace for the author, it turns out the fix was very obvious. Resubmitting this patch as is, and will submit the fix in a followup so that the fix is not hidden in the larger CL. llvm-svn: 304122
* Revert "[X86] Adding new LLVM TableGen backend that generates the X86 ↵Zachary Turner2017-05-293-16/+29
| | | | | | | | | | | | | backend memory folding tables." This reverts commit 28cb1003507f287726f43c771024a1dc102c45fe as well as all subsequent followups. llvm-tblgen currently segfaults with this change, and it seems it has been broken on the bots all day with no fixes in preparation. See, for example: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/ llvm-svn: 304121
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileDavid Blaikie2017-05-291-0/+40
| | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) llvm-svn: 304119
* Attempt to fix buildbots...David Blaikie2017-05-291-0/+0
| | | | llvm-svn: 304118
* DebugInfo: Omit an empty CU when a subprogram was moved into its useDavid Blaikie2017-05-281-0/+52
| | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. llvm-svn: 304111
* [x86] auto-generate better checks; NFCSanjay Patel2017-05-282-59/+204
| | | | llvm-svn: 304090
* [X86] Adding new LLVM TableGen backend that generates the X86 backend memory ↵Ayman Musa2017-05-283-29/+16
| | | | | | | | | | | folding tables. X86 backend holds huge tables in order to map between the register and memory forms of each instruction. This TableGen Backend automatically generated all these tables with the appropriate flags for each entry. Differential Revision: https://reviews.llvm.org/D32684 llvm-svn: 304088
* DebugInfo: Add source code/build instructions for split-dwarf-dwp symbolizer ↵David Blaikie2017-05-271-0/+12
| | | | | | | | | test Addressing post-commit code review feedback from Paul Robinson on r303609. llvm-svn: 304080
* Cloning: Fix debug info cloningGor Nishanov2017-05-271-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I believe https://reviews.llvm.org/rL302576 introduced two bugs: 1) it produces duplicate distinct variables for every: dbg.value describing the same variable. To fix the problme I switched form getDistinct() to get() in DebugLoc.cpp: auto reparentVar = [&](DILocalVariable *Var) { return DILocalVariable::getDistinct( 2) It passes NewFunction plain name as a linkagename parameter to Subprogram constructor. Breaks assert in: || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 # (Edit: reproducer added) Here how https://reviews.llvm.org/rL302576 broke coroutine debug info. Coroutine body of the original function is split into several parts by cloning and removing unneeded code. All parts describe the original function and variables present in the original function. For a simple case, prior to Split, original function has these two blocks: ``` PostSpill: ; preds = %AllocaSpillBB call void @llvm.dbg.value(metadata i32 %x, i64 0, metadata !14, metadata !15), !dbg !13 store i32 %x, i32* %x.addr, align 4 ... and sw.epilog: ; preds = %sw.bb %x.addr.reload.addr = getelementptr inbounds %f.Frame, %f.Frame* %FramePtr, i32 0, i32 4, !dbg !20 %4 = load i32, i32* %x.addr.reload.addr, align 4, !dbg !20 call void @llvm.dbg.value(metadata i32 %4, i64 0, metadata !14, metadata !15), !dbg !13 !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) ``` Note that in two blocks different expression represent the same original user variable X. Before rL302576, for every cloned function there was exactly one cloned DILocalVariable(name: "x" as in: ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ... !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, isOptimized: false, unit: !0, variables: !2) !28 = !DILocalVariable(name: "x", arg: 1, scope: !25, file: !7, line: 55, type: !11) ``` After rL302576, for every cloned function there were as many DILocalVariable(name: "x" as there were "call void @llvm.dbg.value" for that variable. This was causing asserts in VerifyDebugInfo and AssemblyPrinter. Example: ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, !29 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !39 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !41 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) ``` Second problem: Prior to rL302576, all clones were described by DISubprogram referring to original function. ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ``` After rL302576, DISubprogram for clones is of two minds, plain name refers to the original name, linkageName refers to plain name of the clone. ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, ``` I think the assumption in AsmPrinter is that both name and linkageName should refer to the same entity. It asserts here when they are not: ``` || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 ``` After this fix, behavior (with respect to coroutines) reverts to exactly as it was before and therefore making them debuggable again, or even more importantly, compilable, with "-g" Reviewers: dblaikie, echristo, aprantl Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33614 llvm-svn: 304079
* [SCEV] Assume parameters coming from function calls contain IVsTobias Grosser2017-05-271-0/+80
| | | | | | | | | | | | | | | | | | | | The optimistic delinearization implemented in LLVM detects array sizes by looking for non-linear products between parameters and induction variables. In OpenCL code, such products often look like: A[get_global_id(0) * N + get_global_id(1)] Hence, the IV is hidden in the get_global_id() call and consequently delinearization would fail as no induction variable is available that helps us to identify N as array size parameter. We now use a very simple heuristic to change this. We assume that each parameter that comes directly from a function call is a hidden induction variable. As a result, we can delinearize the access above to: A[get_global_id(0)][get_global_id(1] llvm-svn: 304073
* [DAGCombiner] use narrow load to avoid vector extractSanjay Patel2017-05-2712-144/+92
| | | | | | | | | | | | | | | | | | If we have (extract_subvector(load wide vector)) with no other users, that can just be (load narrow vector). This is intentionally conservative. Follow-ups may loosen the one-use constraint to account for the extract cost or just remove the one-use check. The memop chain updating is based on code that already exists multiple times in x86 lowering, so that should be pulled into a helper function as a follow-up. Background: this is a potential improvement noticed via regressions caused by making x86's peekThroughBitcasts() not loop on consecutive bitcasts (see comments in D33137). Differential Revision: https://reviews.llvm.org/D33578 llvm-svn: 304072
* AArch64/PEI: Do not add reserved regs to liveinsMatthias Braun2017-05-271-2/+2
| | | | | | | We do not track liveness for reserved registers. It is unnecessary to add them to block livein lists. llvm-svn: 304059
* [SCEVExpander] Try harder to avoid introducing inttoptrKeno Fischer2017-05-271-0/+45
| | | | | | | | | | | | | | | | Summary: This fixes introduction of an incorrect inttoptr/ptrtoint pair in the included test case which makes use of non-integral pointers. I suspect there are more cases like this left, but this takes care of the one I was seeing at the moment. Reviewers: sanjoy Subscribers: mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D33129 llvm-svn: 304058
* ScheduleDAGInstrs: Fix fixupKills()Matthias Braun2017-05-272-2/+2
| | | | | | | | | | | | Rewrite fixupKills() to use the LivePhysRegs class. Simplifies the code and fixes a bug where the CSR registers in return blocks where missed leading to invalid kill flags. Also remove the unnecessary rule that we wouldn't set kill flags on tied operands. No tests as I have an upcoming commit improving MachineVerifier checks to catch these cases in multiple existing lit tests. llvm-svn: 304055
* [AArch64][GlobalISel] Add the Localizer pass for the O0 pipelineQuentin Colombet2017-05-273-3/+100
| | | | | | | This should fix most of the issue we have right now with constants being spilled all over the place. llvm-svn: 304052
* [GlobalISel] Add a localizer pass for target to useQuentin Colombet2017-05-271-0/+312
| | | | | | | | | | | | | This reverts commit r299287 plus clean-ups. The localizer pass is a helper pass that could be run at O0 in the GISel pipeline to work around the deficiency of the fast register allocator. It basically shortens the live-ranges of the constants so that the allocator does not spill all over the place. Long term fix would be to make the greedy allocator fast. llvm-svn: 304051
* [GVN] Recommit the patch "Add phi-translate support in scalarpre".Wei Mi2017-05-273-4/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recommit is to fix a bug about ExtractValue and InsertValue ops. For those ops, some varargs inside GVN::Expression are not value numbers but raw index numbers. It is wrong to do phi-translate for raw index numbers, and the fix is to stop doing that. Right now scalarpre doesn't have phi-translate support, so it will miss some simple pre opportunities. Like the following testcase, current scalarpre cannot recognize the last "a * b" is fully redundent because a and b used by the last "a * b" expr are both defined by phis. long a[100], b[100], g1, g2, g3; __attribute__((pure)) long goo(); void foo(long a, long b, long c, long d) { g1 = a * b; if (__builtin_expect(g2 > 3, 0)) { a = c; b = d; g2 = a * b; } g3 = a * b; // fully redundant. } The patch adds phi-translate support in scalarpre. This is only a temporary solution before the newpre based on newgvn is available. Differential Revision: https://reviews.llvm.org/D32252 llvm-svn: 304050
* AArch64: Fix cmpxchg O0 expansionMatthias Braun2017-05-262-6/+13
| | | | | | | | | | | | | | - Rewrite livein calculation to use the computeLiveIns() helper function. This is slightly less efficient but easier to reason about and doesn't unnecessarily add pristine and reserved registers[1] - Zero the status register at the beginning of the loop to make sure it has a defined value. - Remove kill flags of values that need to stay alive throughout the loop. [1] An upcoming commit of mine will tighten the MachineVerifier to catch these. llvm-svn: 304048
* Fix test broken by r304020David Blaikie2017-05-261-1/+6
| | | | | | | | | | It's a workaround because the test was flakey passing to begin with, but it looks like (going off commit history) it really did want to test in the presence of debug info, so keep that behavior (by adding something to the CU so it's not dropped) & restore the flakey pass in the process. (added a FIXME in case someone else decides to look at it later) llvm-svn: 304042
* Resubmit r303859 with test fixed.Konstantin Zhuravlyov2017-05-261-0/+15
| | | | | | | | | | [AMDGPU] add intrinsic for s_getpc Summary: The s_getpc instruction is exposed as intrinsic llvm.amdgcn.s.getpc. Patch by Tim Corringham llvm-svn: 304031
* [InstSimplify] Use m_APInt instead of m_ConstantInt in ((V + N) & C1) | (V & ↵Craig Topper2017-05-261-1/+40
| | | | | | | | | | C2) handling in order to support splat vectors. The tests here are have operands commuted to provide more coverage. I also commuted one of the instructions in the scalar tests so the 4 tests cover the 4 commuted variations Differential Revision: https://reviews.llvm.org/D33599 llvm-svn: 304021
* DebugInfo: Do not emit empty CUsDavid Blaikie2017-05-2611-59/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistent with GCC and addresses a shortcoming with ThinLTO where many imported CUs may end up being empty (because the functions imported from them either ended up not being used (and were then discarded, since they're imported as available_externally) or optimized away entirely). Test cases previously testing empty CUs (either intentionally, or because they didn't need anything more complicated) had a trivial 'int' or similar basic type added to their retained types list. This is a first order approximation - a deeper implementation could do things like: 1) Be more lazy about construction of the CU - for example if two CUs containing a single identical retained type are linked together, with this change one of the two CUs will be produced but empty (since a duplicate type won't be produced). 2) Go further and invert all the CU links the same way the subprogram link is inverted - keep named CU lists of retained types, macros, etc, and have those link back to the CU. Then if they're emitted, the CU is emitted, but never otherwise - this would allow the metadata itself to be dropped earlier too, though it seems unlikely that's an important optimization as there shouldn't be many CUs relative to the number of other entities. llvm-svn: 304020
* PMB: Run the whole-program-devirt pass during LTO at --lto-O0.Peter Collingbourne2017-05-261-0/+16
| | | | | | | | | | The whole-program-devirt pass needs to run at -O0 because only it knows about the llvm.type.checked.load intrinsic: it needs to both lower the intrinsic itself and handle it in the summary. Differential Revision: https://reviews.llvm.org/D33571 llvm-svn: 304019
* [AMDGPU][MC][GFX9] Corrected encoding of flat_scratch* for SDWA opcodesDmitry Preobrazhensky2017-05-261-0/+4
| | | | | | | | | | See bug 33171: https://bugs.llvm.org/show_bug.cgi?id=33171 Reviewers: Sam Kolton Differential Revision: https://reviews.llvm.org/D33553 llvm-svn: 304015
* DebugInfo: Don't include locations for debug-having code inlined into ↵David Blaikie2017-05-261-1/+8
| | | | | | | | | | | | | | | nodebug functions This produced 'strange' DWARF anyway - the CU would have no ranges (or at least not a range including the inlined code) nor any subprogram or inlined_subroutine - yet the line table would have entries for these instructions. (this actually becomes more relevant with changes coming after this, where a CU without any contents will be omitted entirely - so there would be no line table to put this on anyway) llvm-svn: 304004
* AMDGPU/GlobalISel: Mark 32-bit float constants as legalTom Stellard2017-05-261-0/+20
| | | | | | | | | | | | Reviewers: arsenm Reviewed By: arsenm Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, igorb, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D33212 llvm-svn: 304003
* LivePhysRegs: Fix addLiveOutsNoPristines() for return blocks past PEIMatthias Braun2017-05-261-0/+52
| | | | | | | | | | | | | | | | | Re-commit r303938 and r303954 with a fix for addLiveIns(): the internal addPristines() function must be called on an empty set or it may accidentally reset saved registers. - addLiveOutsNoPristines() needs to add callee saved registers that are actually saved and restored somewhere to the set (they are not pristine). - Cleanup/rewrite the code for addLiveOuts()/addLiveOutsNoPristines(). This fixes the problem from D32156. Differential Revision: https://reviews.llvm.org/D32464 llvm-svn: 304001
OpenPOWER on IntegriCloud