Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-05-19T19:11:06+00:00 2020-05-19T19:11:06+00:00 David Green david.green@arm.com 2020-04-26T20:58:58+00:00 urn:sha1:f3164f752708753323e2e6a8d17e703cfeb69be6 When compiling for a arm5te cpu from clang, the +dsp attribute is set. This meant we could try and generate qadd8 instructions where we would end up having no pattern. I've changed the condition here to be hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem to use for similar instructions. Fixed PR45677. Differential Revision: https://reviews.llvm.org/D78877 (cherry picked from commit 8807139026b64ac40163bb255dad38a1d8054f08) 2020-05-07T14:27:37+00:00 David Green david.green@arm.com 2020-04-16T14:23:49+00:00 urn:sha1:bab8d1790a33235dfb0e633652ca7fa21d0fb0d0 BreakPHIEdge would be set based on whether the instruction needs to insert a new critical edge to allow sinking into a block where the uses are PHI nodes. But for instructions with multiple defs it would be reset on the second def, allowing the instruciton to sink where it should not. Fixes PR44981 Differential Revision: https://reviews.llvm.org/D78087 (cherry picked from commit 44c4ba34d001dcf538d7396007b5611d6f697f86) 2020-02-25T10:54:51+00:00 Hans Wennborg hans@chromium.org 2020-02-25T10:50:03+00:00 urn:sha1:882720b7ce338c81aa24c1c2b2614c47d248920f The previous patch (cff90f07cb5cc3c3bc58277926103af31caef308) didn't cover ARM. (cherry picked from commit decd021facba804b57e8d80b6159c987d3261ab8) 2020-02-18T15:46:45+00:00 John Brawn john.brawn@arm.com 2020-02-17T16:55:32+00:00 urn:sha1:f636e9feb9f0969e3b563d3140db5a0faa1e30d8 mutateStrictFPToFP can delete the node and replace it with another with the same value which can later cause problems, and returning the result of mutateStrictFPToFP doesn't work because SelectionDAGLegalize expects that the returned value has the same number of results as the original. Instead handle things by doing the mutation manually. Differential Revision: https://reviews.llvm.org/D74726 (cherry picked from commit 594a89f7270da74c89f2321432bc6a7135773fa5) 2020-02-18T15:46:43+00:00 John Brawn john.brawn@arm.com 2020-02-13T14:52:33+00:00 urn:sha1:cbac41966b8f9356a3e69c050b60770108550d1e If the target has FP64 but not FP16 then we have custom lowering for FP_EXTEND and STRICT_FP_EXTEND with type f64. However if the extend is from f32 to f64 the current implementation will cause in infinite loop for STRICT_FP_EXTEND due to emitting a merge_values of the original node which after replacement becomes a merge_values of itself. Fix this by not doing anything for f32 to f64 extend when we have FP64, though for STRICT_FP_EXTEND we have to do the strict-to-nonstrict mutation as that doesn't happen automatically for opcodes with custom lowering. Differential Revision: https://reviews.llvm.org/D74559 (cherry picked from commit 0ec57972967dfb43fc022c2e3788be041d1db730) 2020-02-18T15:46:41+00:00 John Brawn john.brawn@arm.com 2020-01-22T14:04:12+00:00 urn:sha1:19f4aa2d0ad68b99155582f28f0dfe2406c8fe32 These can be lowered to code sequences using CMPFP and CMPFPE which then get selected to VCMP and VCMPE. The implementation isn't fully correct, as the chain operand isn't handled correctly, but resolving that looks like it would involve changes around FPSCR-handling instructions and how the FPSCR is modelled. The fp-intrinsics test was already testing some of this but as the entire test was being XFAILed it wasn't noticed. Un-XFAIL the test and instead leave the cases where we aren't generating the right instruction sequences as FIXME. Differential Revision: https://reviews.llvm.org/D73194 (cherry picked from commit b37d59353f699e99f139a9227a6a69964ef4b132) 2020-02-12T13:06:29+00:00 Jeremy Morse jeremy.morse@sony.com 2020-02-05T17:27:44+00:00 urn:sha1:4eb45a05a78f7c80bbec0453bc225deebec06209 This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref. (cherry picked from commit 6531a78ac4b5b229bce272706593a0bc873877d7) 2020-02-08T13:36:47+00:00 Victor Campos victor.campos@arm.com 2020-02-08T13:36:47+00:00 urn:sha1:7996b49053f0508717f4a081d197ddc3073f4b5f This reverts commit 60e0120c913dd1d4bfe33769e1f000a076249a42. 2020-02-05T12:52:41+00:00 Nikita Popov nikita.ppv@gmail.com 2020-02-02T17:44:18+00:00 urn:sha1:99c6a4ea9201f09e8107bb83675f1e7235456b6d Followup to D73135. If the target doesn't have hard float (default for ARM), then we assert when trying to soften the result of vector reduction intrinsics. This patch marks these for expansion as well. (A bit odd to use vectors on a target without hard float ... but that's where you end up if you expose target-independent vector types.) Differential Revision: https://reviews.llvm.org/D73854 (cherry picked from commit 1cc4f8d17247cd9be88addd75d060f9321b6f8b0) 2020-02-05T12:51:46+00:00 Nikita Popov nikita.ppv@gmail.com 2020-01-21T20:48:07+00:00 urn:sha1:0b8a540dff86662fc9426bb4dd8797c547db5000 fadd/fmul reductions without reassoc are lowered to VECREDUCE_STRICT_FADD/FMUL nodes, which don't have legalization support. Until that is in place, expand these intrinsics on ARM and AArch64. Other targets always expand the vector reduction intrinsics. Additionally expand fmax/fmin reductions without nonan flag on AArch64, as the backend asserts that the flag is present when lowering VECREDUCE_FMIN/FMAX. This fixes https://bugs.llvm.org/show_bug.cgi?id=44600. Differential Revision: https://reviews.llvm.org/D73135 (cherry picked from commit 70d345e687caba4ac1f95655c6924dfa91e0083f)