summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAGCombine] (A+C1)-C2 -> A+(C1-C2) constant-foldRoman Lebedev2019-05-301-0/+10
| | | | | | | | | | | | | | | | | | | Summary: Direct sibling of D62662, the root cause of the endless combine loop in D62257 https://rise4fun.com/Alive/d3W Reviewers: RKSimon, craig.topper, spatel, t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62664 llvm-svn: 362133
* [DAGCombine] Use FoldConstantArithmetic() to perform C2-(A+C1) -> (C2-C1)-A foldRoman Lebedev2019-05-301-1/+3
| | | | | | | | | | | | | | | | | Summary: No tests change, and i'm not sure how to test this, but it's better safe than sorry. Reviewers: spatel, RKSimon, craig.topper, t.p.northover Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62663 llvm-svn: 362132
* [DAGCombine] ((A-c1)+c2) -> (A+(c2-c1)) constant-foldRoman Lebedev2019-05-301-0/+9
| | | | | | | | | | | | | | | | | | | Summary: This was the root cause of the endless combine loop in D62257 https://rise4fun.com/Alive/d3W Reviewers: RKSimon, spatel, craig.topper, t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62662 llvm-svn: 362131
* [DAGCombine] Use FoldConstantArithmetic() to perform ((c1-A)+c2) -> ↵Roman Lebedev2019-05-301-4/+4
| | | | | | | | | | | | | | | | | | (c1+c2)-A fold Summary: No tests change, and i'm not sure how to test this, but it's better safe than sorry. Reviewers: spatel, RKSimon, craig.topper, t.p.northover Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62661 llvm-svn: 362130
* Reapply: IR: add optional type to 'byval' function parametersTim Northover2019-05-304-9/+23
| | | | | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
* [MIR-Canon] Add support for rewriting VRegs that are typed but don't have an RC.Puyan Lotfi2019-05-301-5/+6
| | | | | | | | | | | There were crashes (addrspace-memoperands.mir was only one of them) in MIR that had operands that came from before register classes were set. With these operands, creating a replacement vreg (for MIR-Canon's renaming) needs to use the vreg type rather than the RegisterClass which is not present. Differential Revision: https://reviews.llvm.org/D62543 llvm-svn: 362122
* Correct error in revert of r362112.Kevin P. Neal2019-05-301-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D62546 llvm-svn: 362118
* Revert r362112, it broke the bots with the message "Unsupported vector ↵Kevin P. Neal2019-05-302-63/+1
| | | | | | | | argument or return type" Differential Revision: http://reviews.llvm.org/D62546 llvm-svn: 362117
* [FPEnv] Added a special UnrollVectorOp method to deal with the chain on ↵Kevin P. Neal2019-05-302-1/+63
| | | | | | | | | | | | | StrictFP opcodes This change creates UnrollVectorOp_StrictFP. The purpose of this is to address a failure that consistently occurs when calling StrictFP functions on vectors whose number of elements is 3 + 2n on most platforms, such as PowerPC or SystemZ. The old UnrollVectorOp method does not expect that the vector that it will unroll will have a chain, so it has an assert that prevents it from running if this is the case. This new StrictFP version of the method deals with the chain while unrolling the vector. With this new function in place during vector widending, llc can run vector-constrained-fp-intrinsics.ll for SystemZ successfully. Submitted by: Drew Wock <drew.wock@sas.com> Reviewed by: Cameron McInally, Kevin P. Neal Approved by: Cameron McInally Differential Revision: http://reviews.llvm.org/D62546 llvm-svn: 362112
* [DAGCombine] Revert of recommit of "binop-with-const hoisting" patchesRoman Lebedev2019-05-301-34/+0
| | | | | | | | | | | | | | I was looking into an endless combine loop the uncommitted follow-up patch was causing, and it appears even these patches can exibit such an endless loop. The root cause is that we try to hoist one binop (add/sub) with constant operand, and if we get two such binops both of which are eligible for this hoisting, we get stuck. Some cases may highlight missing constant-folds. Reverts r361871,r361872,r361873,r361874. llvm-svn: 362109
* CodeView - add static data members to global variable debug info.Amy Huang2019-05-291-1/+6
| | | | | | | | | | | | | | | | | | Summary: Add static data members to IR debug info's list of global variables so that they are emitted as S_CONSTANT records. Related to https://bugs.llvm.org/show_bug.cgi?id=41615. Reviewers: rnk Subscribers: aprantl, cfe-commits, llvm-commits, thakis Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62167 llvm-svn: 362038
* Revert "IR: add optional type to 'byval' function parameters"Tim Northover2019-05-294-23/+9
| | | | | | | The IRLinker doesn't delve into the new byval attribute when mapping types, and this breaks LTO. llvm-svn: 362029
* [DAGCombiner] Replace gathers with a zero mask with the passthru valueBenjamin Kramer2019-05-291-3/+7
| | | | | | | | | | These can be created by the legalizer when splitting a larger gather. See https://llvm.org/PR42055 for a motivating example. Differential Revision: https://reviews.llvm.org/D62613 llvm-svn: 362015
* IR: add optional type to 'byval' function parametersTim Northover2019-05-294-9/+23
| | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362012
* Qualify use of llvm::empty that's ambiguous with std::emptySam McCall2019-05-291-1/+1
| | | | llvm-svn: 361968
* Inline a variable into debug section to fix unused variable warning.Richard Trieu2019-05-291-2/+2
| | | | llvm-svn: 361927
* Inline value into debug statement to avoid unused variable warning.Richard Trieu2019-05-291-3/+2
| | | | llvm-svn: 361924
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-291-0/+18
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* Support resource tracking with InstrSchedModelJinsong Ji2019-05-291-32/+209
| | | | | | | | | | | | The current design use DFA to do resource tracking in SMS, and DFA only support InstrItins, and also has scaling limitation. This patch extend SMS to allow Subtarget to use ProcResource in InstrSchedModel instead. Differential Revision: https://reviews.llvm.org/D62163 llvm-svn: 361919
* Revert "[X86] Use 'llvm_unreachable' instead of nullptr in unreachable code to"Pengfei Wang2019-05-291-3/+1
| | | | | | This reverts commit c1b3716614bc0a107e6f41a7d3d503baefad8a5b. llvm-svn: 361918
* [X86] Use 'llvm_unreachable' instead of nullptr in unreachable code toPengfei Wang2019-05-291-1/+3
| | | | | | | | | | | | | | | | | avoid static check fail RegClassOrBank is an object of RegClassOrRegBank, which is defined as using llvm::RegClassOrRegBank = typedef PointerUnion<const TargetRegisterClass *, const RegisterBank *> so control flow can not get here. Use ""llvm_unreachable" here to avoid "null pointer" confusion. Patch by Shengchen Kan (skan) Differential Revision: https://reviews.llvm.org/D62006 Signed-off-by: pengfei <pengfei.wang@intel.com> llvm-svn: 361912
* [RegUsageInfoCollector] Don't mark as saved registers that don't have ↵Quentin Colombet2019-05-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subregister lanes To determine the list of clobbered registers, the RegUsageInfoCollector pass uses the list of callee saved registers provided by the target and then augments it with the list of registers which have all their subregisters saved. It then basically does the difference between all the registers and the saved registers to come up with what is clobbered (plus it checks that the register is defined within that functions). The patch fixes a bug where when register does not have any subregister lane, hence when checking if any of its subregister are not saved, we would find none and think the register is saved as well. That's obviously wrong. The code was actually kind of checking for something like that with the CoveredBySubRegs bit. What this bit says is that a register is completely covered by its subregisters. We required that this bit was set, to check that a register was saved by its subregister lanes, since without this bit, we potentially would miss to check some part of the register. However, this bit is used de facto on registers that don't have any subregisters (e.g., on ARM) and the code was not prepared for that. This patch fixes this by checking that a register has subregisters before declaring it saved when none of its lanes are modified. llvm-svn: 361901
* [CodeGen] Add lrint/llrint builtinsAdhemerval Zanella2019-05-287-1/+111
| | | | | | | | | | | | | | | | | This patch add the ISD::LRINT and ISD::LLRINT along with new intrinsics. The changes are straightforward as for other floating-point rounding functions, with just some adjustments required to handle the return value being an interger. The idea is to optimize lrint/llrint generation for AArch64 in a subsequent patch. Current semantic is just route it to libm symbol. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D62017 llvm-svn: 361875
* [DAGCombine] (x - C) - y -> (x - y) - C fold. Try 2Roman Lebedev2019-05-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: Again only vectors affected. Frustrating. Let me take a look into that.. https://rise4fun.com/Alive/AAq This is a recommit, originally committed in rL361856, but reverted to investigate test-suite compile-time hangs. Reviewers: RKSimon, craig.topper, spatel Reviewed By: RKSimon Subscribers: javed.absar, JDevlieghere, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62294 llvm-svn: 361874
* [DAGCombine][X86][AArch64][AMDGPU] (x - y) + -1 -> add (xor y, -1), x ↵Roman Lebedev2019-05-281-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | fold. Try 2 Summary: This prevents regressions in next patch, and somewhat recovers from the regression to AMDGPU test in D62223. It is indeed not great that we leave vector decrement, don't transform it into vector add all-ones.. https://rise4fun.com/Alive/ZRl This is a recommit, originally committed in rL361855, but reverted to investigate test-suite compile-time hangs. Reviewers: RKSimon, craig.topper, spatel, arsenm Reviewed By: RKSimon, arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62263 llvm-svn: 361873
* [DAGCombiner][X86][AArch64][SPARC][SystemZ] y - (x + C) -> (y - x) - C ↵Roman Lebedev2019-05-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fold. Try 2 Summary: Direct sibling of D62223 patch. While i don't have a direct motivational pattern for this, it would seem to make sense to handle both patterns (or none), for symmetry? The aarch64 changes look neutral; sparc and systemz look like improvement (one less instruction each); x86 changes - 32bit case improves, 64bit case shows that LEA no longer gets constructed, which may be because that whole test is `-mattr=+slow-lea,+slow-3ops-lea` https://rise4fun.com/Alive/ffh This is a recommit, originally committed in rL361853, but reverted to investigate test-suite compile-time hangs. Reviewers: RKSimon, craig.topper, spatel, t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, jyknight, javed.absar, kristof.beyls, fedor.sergeev, jrtc27, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62252 llvm-svn: 361872
* [DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C fold. Try 2Roman Lebedev2019-05-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main motivation is shown by all these `neg` instructions that are now created. In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test. AArch64 test changes all look good (`neg` created), or neutral. X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created). I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill is now hoisted into preheader (which should still be good?), 2 4-byte reloads become 1 8-byte reload, and are elsewhere, but i'm not sure how that affects that loop. I'm unable to interpret AMDGPU change, looks neutral-ish? This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]]. https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later) This is a recommit, originally committed in rL361852, but reverted to investigate test-suite compile-time hangs. Reviewers: craig.topper, RKSimon, spatel, arsenm Reviewed By: RKSimon Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62223 llvm-svn: 361871
* Revert DAGCombine "hoist binop with const" foldsRoman Lebedev2019-05-281-42/+0
| | | | | | | | | | Appear to introduce test-suite compile-time hang. http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/22825 This reverts r361852,r361853,r361854,r361855,r361856 llvm-svn: 361865
* [DAGCombine] (x - C) - y -> (x - y) - C foldRoman Lebedev2019-05-281-0/+7
| | | | | | | | | | | | | | | | | | | Summary: Again only vectors affected. Frustrating. Let me take a look into that.. https://rise4fun.com/Alive/AAq Reviewers: RKSimon, craig.topper, spatel Reviewed By: RKSimon Subscribers: javed.absar, JDevlieghere, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62294 llvm-svn: 361856
* [DAGCombine][X86][AArch64][AMDGPU] (x - y) + -1 -> add (xor y, -1), x foldRoman Lebedev2019-05-281-0/+14
| | | | | | | | | | | | | | | | | | | | | | | Summary: This prevents regressions in next patch, and somewhat recovers from the regression to AMDGPU test in D62223. It is indeed not great that we leave vector decrement, don't transform it into vector add all-ones.. https://rise4fun.com/Alive/ZRl Reviewers: RKSimon, craig.topper, spatel, arsenm Reviewed By: RKSimon, arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62263 llvm-svn: 361855
* [DAGCombiner][X86][AArch64] (x - C) + y -> (x + y) - C foldRoman Lebedev2019-05-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: Only vector tests are being affected here, since subtraction by scalar constant is rewritten as addition by negated constant. No surprising test changes. https://rise4fun.com/Alive/pbT Reviewers: RKSimon, craig.topper, spatel Reviewed By: RKSimon Subscribers: javed.absar, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62257 llvm-svn: 361854
* [DAGCombiner][X86][AArch64][SPARC][SystemZ] y - (x + C) -> (y - x) - C foldRoman Lebedev2019-05-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Direct sibling of D62223 patch. While i don't have a direct motivational pattern for this, it would seem to make sense to handle both patterns (or none), for symmetry? The aarch64 changes look neutral; sparc and systemz look like improvement (one less instruction each); x86 changes - 32bit case improves, 64bit case shows that LEA no longer gets constructed, which may be because that whole test is `-mattr=+slow-lea,+slow-3ops-lea` https://rise4fun.com/Alive/ffh Reviewers: RKSimon, craig.topper, spatel, t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, jyknight, javed.absar, kristof.beyls, fedor.sergeev, jrtc27, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62252 llvm-svn: 361853
* [DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y -> (x - y) + C foldRoman Lebedev2019-05-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main motivation is shown by all these `neg` instructions that are now created. In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test. AArch64 test changes all look good (`neg` created), or neutral. X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created). I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill is now hoisted into preheader (which should still be good?), 2 4-byte reloads become 1 8-byte reload, and are elsewhere, but i'm not sure how that affects that loop. I'm unable to interpret AMDGPU change, looks neutral-ish? This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]]. https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later) Reviewers: craig.topper, RKSimon, spatel, arsenm Reviewed By: RKSimon Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62223 llvm-svn: 361852
* [DAG] LegalizeVectorTypes - reduce scope of local variables. NFCI.Simon Pilgrim2019-05-281-4/+2
| | | | | | Move the element index/count variables into the block where they are actually used - appeases cppcheck and helps avoid shadow variable warnings. llvm-svn: 361821
* Stop undef fragments from closing non-overlapping fragmentsDavid Stenberg2019-05-282-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When DwarfDebug::buildLocationList() encountered an undef debug value, it would truncate all open values, regardless if they were overlapping or not. This patch fixes so that it only does that for overlapping fragments. This change unearthed a bug that I had introduced in D57511, which I have fixed in this patch. The code in DebugHandlerBase that changes labels for parameter debug values could break DwarfDebug's assumption that the labels for the entries in the debug value history are monotonically increasing. Before this patch, that bug could result in location list entries whose ending address was lower than the beginning address, and with the changes for undef debug values that this patch introduces it could trigger an assertion, due to attempting to emit location list entries with empty ranges. A reproducer for the bug is added in param-reg-const-mix.mir. Reviewers: aprantl, jmorse, probinson Reviewed By: aprantl Subscribers: javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D62379 llvm-svn: 361820
* MIR: Fix printer crashing on dead CSR frame indexesMatt Arsenault2019-05-281-0/+3
| | | | llvm-svn: 361819
* [X86] Custom lower CONCAT_VECTORS of v2i1Benjamin Kramer2019-05-281-0/+1
| | | | | | | The generic legalizer cannot handle this. Add an assert instead of silently miscompiling vectors with elements smaller than 8 bits. llvm-svn: 361814
* RegAllocFast: Set MayLiveAcrossBlocks when allocating usesMatt Arsenault2019-05-271-1/+27
| | | | | | | | | | Setting mayLiveOut based only on use instructions after allocating the def block did not work if the use block was allocated before the def block, since the virtual register uses were already removed. Fixes bug 41973. llvm-svn: 361781
* [SelectionDAG] fold concat of extract subvectorsSanjay Patel2019-05-271-0/+25
| | | | | | | | | | | | | | This is derived from the related fold for build vectors. We also have a version of this in DAGCombiner. The benefit of having this fold at node creation time is (1) efficiency and (2) preventing infinite looping from creating patterns that should not exist in the first place. Currently, the inf-loop could happen with MergeConsecutiveStores() because it naively creates concat of extracts when forming a wider vector store. That could fight with target-specific store narrowing. llvm-svn: 361780
* [SelectionDAG] fix formatting and redundant comments; NFCSanjay Patel2019-05-271-7/+6
| | | | | | | | | There's a possible missing fold here for extracting from the same source vector. It's similar to a check that we use to squash a build vector with all extracted elements from the same source vector. llvm-svn: 361778
* [SelectionDAG] Enhance the simplification of `copyto` from `implicit-def`.Michael Liao2019-05-272-31/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - The current implementation simplifies the case where the source of `copyto` is `implicit-def`ed. However, it only works when that `implicit-def` is single-used since it detects that from `implicit-def` and cannot determine which destination vreg should be used if there are multiple uses. - This patch changes that detection when `copyto` is being emitted. If that `copyto`'s source is defined from `implicit-def`, it simplifies it. Hence, it works even that `implicit-def` is multi-used. - Except it simplifies the internal IR, it won't improve the quality of code generation. However, it helps to detect 'implicit-def` in a straight-forward manner in some passes, such as `si-i1-copies`. A test case is added. Reviewers: sunfish, nhaehnle Subscribers: jvesely, hiraditya, asbirlea, llvm-commits, yaxunl Tags: #llvm Differential Revision: https://reviews.llvm.org/D62342 llvm-svn: 361777
* [SelectionDAG] GetDemandedBits - add demanded elements wrapper implementationSimon Pilgrim2019-05-271-1/+15
| | | | | | The DemandedElts variable is pretty much inert at the moment - the original GetDemandedBits implementation calls it with an 'all ones' DemandedElts value so the function is active and behaves exactly as it used to. llvm-svn: 361773
* Test commit (NFC)Nikola Prica2019-05-271-0/+1
| | | | | | Add blank line. llvm-svn: 361761
* Revert r361356: "[MIR] Add simple PRE pass to MachineCSE"David L. Jones2019-05-271-113/+9
| | | | | | | | This is problematic on buildbots, as discussed here: https://reviews.llvm.org/rL361356 It seems like the plan already was to revert, but that hasn't happened yet. llvm-svn: 361746
* [AMDGPU] Divergence driven ISel. Assign register class for cross block ↵Alexander Timofeev2019-05-266-24/+37
| | | | | | | | | | | | | | | | | | values according to the divergence. Details: To make instruction selection really divergence driven it is necessary to assign the correct register classes to the cross block values beforehand. For the divergent targets same value type requires different register classes dependent on the value divergence. Reviewers: rampitec, nhaehnle Differential Revision: https://reviews.llvm.org/D59990 This commit was reverted because of the build failure. The reason was mlformed patch. Build failure fixed. llvm-svn: 361741
* [SelectionDAG] GetDemandedBits - cleanup to more closely match ↵Simon Pilgrim2019-05-261-16/+21
| | | | | | | | SimplifyDemandedBits. NFCI. Prep work before adding demanded elts support. llvm-svn: 361739
* [SelectionDAG] MaskedValueIsZero - add demanded elements implementationSimon Pilgrim2019-05-261-2/+15
| | | | | | Will be used in an upcoming patch but I've updated the original implementation to call this to ensure test coverage. llvm-svn: 361738
* [SelectionDAG] soften assertion when legalizing narrow vector FP opsSanjay Patel2019-05-251-6/+4
| | | | | | | | | | The test based on PR42010: https://bugs.llvm.org/show_bug.cgi?id=42010 ...may show an inaccuracy for PPC's target defs, but we should not be so aggressive with an assert here. There's no telling what out-of-tree targets look like. llvm-svn: 361696
* Revert r361644, "[AMDGPU] Divergence driven ISel. Assign register class for ↵Peter Collingbourne2019-05-256-37/+24
| | | | | | | | | | cross block values according to the divergence." Broke sanitizer bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/21694/steps/bootstrap%20clang/logs/stdio http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/32478/steps/check-llvm%20asan/logs/stdio llvm-svn: 361688
* [AMDGPU] Divergence driven ISel. Assign register class for cross block ↵Alexander Timofeev2019-05-246-24/+37
| | | | | | | | | | | | | | values according to the divergence. Details: To make instruction selection really divergence driven it is necessary to assign the correct register classes to the cross block values beforehand. For the divergent targets same value type requires different register classes dependent on the value divergence. Reviewers: rampitec, nhaehnle Differential Revision: https://reviews.llvm.org/D59990 llvm-svn: 361644
OpenPOWER on IntegriCloud