Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-24T23:57:33+00:00 2019-12-24T23:57:33+00:00 Fangrui Song maskray@google.com 2019-12-24T23:52:21+00:00 urn:sha1:502a77f125f43ffde57af34d3fd1b900248a91cd 2019-07-07T18:57:31+00:00 Martin Storsjo martin@martin.st 2019-07-07T18:57:31+00:00 urn:sha1:8d9d290d4c0752626374dc681a3417113e08c862 Heavily based on the same for AArch64, from SVN r346469. Differential Revision: https://reviews.llvm.org/D64292 llvm-svn: 365283 2019-07-03T00:30:47+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2019-07-03T00:30:47+00:00 urn:sha1:4f3472deb28b772c82323a849eddd9b67f1cdc31 The BUNDLE itself should not have side effects, and this is a property of instructions inside the bundle. The hasProperty check already searches for any member instructions, which was pointless since it was overridden by this bit. Allows me to distinguish bundles that have side effects vs. do not in a future patch. Also fixes an unnecessary scheduling barrier in the bundle AMDGPU uses to get PC relative addresses. llvm-svn: 364984 2019-06-19T00:25:39+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2019-06-19T00:25:39+00:00 urn:sha1:9cac4e6d1403554b06ec2fc9d834087b1234b695 This allows targets to make more decisions about reserved registers after isel. For example, now it should be certain there are calls or stack objects in the frame or not, which could have been introduced by legalization. Patch by Matthias Braun llvm-svn: 363757 2019-03-19T19:01:34+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2019-03-19T19:01:34+00:00 urn:sha1:c2e35a6f3258d102b731c77de9530714c4d02802 The 2nd loop calculates spill costs but reports free registers as cost 0 anyway, so there is little benefit from having a separate early loop. Surprisingly this is not NFC, as many register are marked regDisabled so the first loop often picks up later registers unnecessarily instead of the first one available in the allocation order... Patch by Matthias Braun llvm-svn: 356499 2019-01-14T10:55:55+00:00 Francis Visoiu Mistrih francisvm@yahoo.com 2019-01-14T10:55:55+00:00 urn:sha1:b7cef81fd36c85e52b115b9ed6d1fb92d63781d6 Part of the effort to refactoring frame pointer code generation. We used to use two function attributes "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" to represent three kinds of frame pointer usage: (all) frames use frame pointer, (non-leaf) frames use frame pointer, (none) frame use frame pointer. This CL makes the idea explicit by using only one enum function attribute "frame-pointer" Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such as llc. "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are still supported for easy migration to "frame-pointer". tests are mostly updated with // replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’ grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g" // replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’ grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g" Patch by Yuanfang Chen (tabloid.adroit)! Differential Revision: https://reviews.llvm.org/D56351 llvm-svn: 351049 2018-10-30T15:04:40+00:00 Jonas Paulsson paulsson@linux.vnet.ibm.com 2018-10-30T15:04:40+00:00 urn:sha1:611b533f1d544b85f1a98afbc9241deeb97d9497 The SchedModel allows the addition of ReadAdvances to express that certain operands of the instructions are needed at a later point than the others. RegAlloc may add pseudo operands that are not part of the instruction descriptor, and therefore cannot have any read advance entries. This meant that in some cases the desired read advance was nullified by such a pseudo operand, which still had the original latency. This patch fixes this by making sure that such pseudo operands get a zero latency during DAG construction. Review: Matthias Braun, Ulrich Weigand. https://reviews.llvm.org/D49671 llvm-svn: 345606 2018-08-31T08:00:25+00:00 Martin Storsjo martin@martin.st 2018-08-31T08:00:25+00:00 urn:sha1:2dcaa41e1ef234a3387a2cb83288252b90c22fb8 The runtime pseudo relocations can't handle the ARM format embedded addresses in movw/movt pairs. By using stubs, the potentially dllimported addresses can be touched up by the runtime pseudo relocation framework. Differential Revision: https://reviews.llvm.org/D51450 llvm-svn: 341176 2018-08-10T21:21:53+00:00 Eli Friedman efriedma@codeaurora.org 2018-08-10T21:21:53+00:00 urn:sha1:e1687a89e885c89b3a1f75c9ab35d5bb74a62869 LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472 2018-05-14T21:32:52+00:00 Martin Storsjo martin@martin.st 2018-05-14T21:32:52+00:00 urn:sha1:ace7ae935ffc181b79d5a22d58589949191b3416 Differential Revision: https://reviews.llvm.org/D46777 llvm-svn: 332298