Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-22T21:58:57+00:00 2020-06-22T21:58:57+00:00 Ahsan Saghir saghir.ibm@gmail.com 2020-05-22T19:35:13+00:00 urn:sha1:3428405fc4ec18b566d64bb1478acd631ccd40f4 This patch adds support for Vector Multiply-Sum Unsigned Doubleword Modulo instruction; vmsumudm. Differential Revision: https://reviews.llvm.org/D80294 (cherry picked from commit a28e9f1208608f8d18750bb88ca74722fb0bcce4) 2020-05-19T19:16:37+00:00 Dimitry Andric dimitry@andric.com 2020-05-12T10:33:15+00:00 urn:sha1:f79cd71e145c6fd005ba4dd1238128dfa0dc2cb6 Summary: In 2e24219d3cbf, a number of ARM pcrel fixups were resolved at assembly time, to solve PR44929. This only covered little-endian ARM however, so add similar fixups for big-endian ARM. Also extend the test case to cover big-endian ARM. Reviewers: hans, psmith, MaskRay Reviewed By: psmith, MaskRay Subscribers: kristof.beyls, hiraditya, danielkiss, emaste, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79774 (cherry picked from commit fc373522b044e0b150561204958f0d603fb4caba) 2020-02-27T11:44:06+00:00 Hans Wennborg hans@chromium.org 2020-02-27T11:35:10+00:00 urn:sha1:058a8cd73f33ae7be7bef469c1b7c2d5fdaa4b24 MC currently does not emit these relocation types, and lld does not handle them. Add FKF_Constant as a work-around of some ARM code after D72197. Eventually we probably should implement these relocation types. By Fangrui Song! Differential revision: https://reviews.llvm.org/D72892 (cherry picked from commit 2e24219d3cbfcb8c824c58872f97de0a2e94a7c8) 2020-01-23T17:27:29+00:00 James Clarke jrtc27@jrtc27.com 2020-01-23T02:05:46+00:00 urn:sha1:8634a82910eba78279a69fcba0925d3a602a0563 Summary: Previously, we would erroneously turn %pcrel_lo(label), where label has a %pcrel_hi against a weak symbol, into %pcrel_lo(label + offset), as evaluatePCRelLo would believe the target independent logic was going to fold it. Moreover, even if that were fixed, shouldForceRelocation lacks an MCAsmLayout and thus cannot evaluate the %pcrel_hi fixup to a value and check the symbol, so we would then erroneously constant-fold the %pcrel_lo whilst leaving the %pcrel_hi intact. After D72197, this same sequence also occurs for symbols with global binding, which is triggered in real-world code. Instead, as discussed in D71978, we introduce a new FKF_IsTarget flag to avoid these kinds of issues. All the resolution logic happens in one place, with no coordination required between RISCAsmBackend and RISCVMCExpr to ensure they implement the same logic twice. Although the implementation of %pcrel_hi can be left as target independent, we make it target dependent to ensure that they are handled identically to %pcrel_lo, otherwise we risk one of them being constant folded but the other being preserved. This also allows us to properly support fixup pairs where the instructions are in different fragments. Reviewers: asb, lenary, efriedma Reviewed By: efriedma Subscribers: arichardson, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73211 (cherry picked from commit 3f5976c97dbfefb4669abcf968bd79a9a64c18e0) 2020-01-15T02:17:53+00:00 Philip Reames listmail@philipreames.com 2020-01-15T02:16:02+00:00 urn:sha1:1a7398eca2040d232149f18a75b5d78a6521941c This flag was originally part of D70157, but was removed as we carved away pieces of the review. Since we have the nop support checked in, and it appears mature(*), I think it's time to add the master flag. For now, it will default to nop padding, but once the prefix padding support lands, we'll update the defaults. (*) I can now confirm that downstream testing of the changes which have landed to date - nop padding and compiler support for suppressions - is passing all of the functional testing we've thrown at it. There might still be something lurking, but we've gotten enough coverage to be confident of the basic approach. Note that the new flag can be used either when assembling an .s file, or when using the integrated assembler directly from the compiler. The later will use all of the suppression mechanism and should always generate correct code. We don't yet have assembly syntax for the suppressions, so passing this directly to the assembler w/a raw .s file may result in broken code. Use at your own risk. Also note that this isn't the wiring for the clang option. I think the most recent review for that is D72227, but I've lost track, so that might be off. Differential Revision: https://reviews.llvm.org/D72738 2020-01-14T11:47:19+00:00 Diogo Sampaio diogo.sampaio@arm.com 2020-01-13T11:36:02+00:00 urn:sha1:d94d079a6a5b12156e4b818c8ba46eb143f335b9 Summary: This patch fixes pr23772 [ARM] r226200 can emit illegal thumb2 instruction: "sub sp, r12, #80". The violation was that SUB and ADD (reg, immediate) instructions can only write to SP if the source register is also SP. So the above instructions was unpredictable. To enforce that the instruction t2(ADD|SUB)ri does not write to SP we now enforce the destination register to be rGPR (That exclude PC and SP). Different than the ARM specification, that defines one instruction that can read from SP, and one that can't, here we inserted one that can't write to SP, and other that can only write to SP as to reuse most of the hard-coded size optimizations. When performing this change, it uncovered that emitting Thumb2 Reg plus Immediate could not emit all variants of ADD SP, SP #imm instructions before so it was refactored to be able to. (see test/CodeGen/Thumb2/mve-stacksplot.mir where we use a subw sp, sp, Imm12 variant ) It also uncovered a disassembly issue of adr.w instructions, that were only written as SUBW instructions (see llvm/test/MC/Disassembler/ARM/thumb2.txt). Reviewers: eli.friedman, dmgreen, carwil, olista01, efriedma, andreadb Reviewed By: efriedma Subscribers: gbedwell, john.brawn, efriedma, ostannard, kristof.beyls, hiraditya, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70680 2020-01-14T08:20:51+00:00 Jay Foad jay.foad@amd.com 2020-01-13T13:52:02+00:00 urn:sha1:440ce5164f52a6b7cdf70322cc1c95656cac9aa9 Summary: Depends on D72611. Reviewers: rampitec, arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72616 2020-01-14T08:20:50+00:00 Jay Foad jay.foad@amd.com 2020-01-13T13:39:52+00:00 urn:sha1:0950de264e37264b9f767a898bd839d9fcb7328f Summary: This adds checks that the expected error was actually reported against the correct instruction, and fixes a couple of problems that that showed up: one incorrect W32-ERR: v_cmp_class_f16_sdwa vcc, v1, v2 src0_sel:DWORD src1_sel:DWORD // W64: encoding: [0xf9,0x04,0x1e,0x7d,0x01,0x00,0x06,0x06] -// W32-ERR: error: invalid operand for instruction +// W32-ERR: error: {{instruction not supported on this GPU|invalid operand for instruction}} and one missing W32-ERR: v_cmp_class_f16_sdwa s[6:7], v1, v2 src0_sel:DWORD src1_sel:DWORD // W64: encoding: [0xf9,0x04,0x1e,0x7d,0x01,0x86,0x06,0x06] +// W32-ERR: error: invalid operand for instruction Reviewers: rampitec, arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72611 2020-01-14T08:20:28+00:00 Jay Foad jay.foad@amd.com 2020-01-12T21:33:11+00:00 urn:sha1:63c3691f79179db9a16f260f1cf81475fdfef060 Summary: This adds assembler tests for cases that were previously only in the disassembler tests, and vice versa. Reviewers: rampitec, arsenm, nhaehnle Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72592 2020-01-14T07:36:06+00:00 Fangrui Song maskray@google.com 2020-01-14T07:35:57+00:00 urn:sha1:0136f226c4e46258ea73fcb994f6559cec4a9aa2