Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=ortega-7.0.1 2018-09-10T08:11:26+00:00 2018-09-10T08:11:26+00:00 Hans Wennborg hans@hanshq.net 2018-09-10T08:11:26+00:00 urn:sha1:3472e2a5a51ff45ddf7a62dec3ce7a0451f04fa3 ------------------------------------------------------------------------ r341642 | tnorthover | 2018-09-07 11:21:25 +0200 (Fri, 07 Sep 2018) | 8 lines ARM: fix Thumb2 CodeGen for ldrex with folded frame-index. Because t2LDREX (& t2STREX) were marked as AddrModeNone, but did allow a FrameIndex operand, rewriteT2FrameIndex asserted. This gives them a proper addressing-mode and tells the rewriter about it so that encodable offsets are exploited and others are rejected. Should fix PR38828. ------------------------------------------------------------------------ llvm-svn: 341783 2018-07-31T09:27:01+00:00 Martin Storsjo martin@martin.st 2018-07-31T09:27:01+00:00 urn:sha1:af18947f0a38dd7385479732474d4865e68fa7a8 Contrary to ELF, we don't add any markers that distinguish data generated with .short/.long from normal instructions, so the .inst directive only adds compatibility with assembly that uses it. Differential Revision: https://reviews.llvm.org/D49936 llvm-svn: 338356 2018-07-30T19:41:25+00:00 Fangrui Song maskray@google.com 2018-07-30T19:41:25+00:00 urn:sha1:f78650a8deca216b858827ff430972c114a60a7a sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293 2018-07-06T08:03:12+00:00 Sjoerd Meijer sjoerd.meijer@arm.com 2018-07-06T08:03:12+00:00 urn:sha1:2a57b357a3a0de2202a3fb0272d2648a205bcdfa This adds the Armv8.4-A Trace synchronization barrier (TSB) instruction. Differential Revision: https://reviews.llvm.org/D48918 llvm-svn: 336418 2018-06-29T08:43:19+00:00 Sjoerd Meijer sjoerd.meijer@arm.com 2018-06-29T08:43:19+00:00 urn:sha1:195e9040022e6516fbd26b46b712c15465edecbc Initial patch adding assembly support for Armv8.4-A. Besides adding v8.4 as a supported architecture to the usual places, this also adds target features for the different crypto algorithms. Armv8.4-A introduced new crypto algorithms, made them optional, and allows different combinations: - none of the v8.4 crypto functions are supported, which is independent of the implementation of the Armv8.0 SHA1 and SHA2 instructions. - the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0 SHA1 and SHA2 instructions must also be implemented. - the v8.4 SM3 and SM4 support is implemented, which is independent of the implementation of the Armv8.0 SHA1 and SHA2 instructions. - all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1 and SHA2 instructions must also be implemented. The v8.4 crypto instructions are added to AArch64 only, and not AArch32, and are made optional extensions to Armv8.2-A. The user-facing Clang options will map on these new target features, their naming will be compatible with GCC and added in follow-up patches. The Armv8.4-A instruction sets can be downloaded here: https://developer.arm.com/products/architecture/a-profile/exploration-tools Differential Revision: https://reviews.llvm.org/D48625 llvm-svn: 335953 2018-06-06T09:40:06+00:00 Peter Smith peter.smith@linaro.org 2018-06-06T09:40:06+00:00 urn:sha1:57f661bd7d20412f21ac6b7611c41a0f8b84fc01 On targets like Arm some relaxations may only be performed when certain architectural features are available. As functions can be compiled with differing levels of architectural support we must make a judgement on whether we can relax based on the MCSubtargetInfo for the function. This change passes through the MCSubtargetInfo for the function to fixupNeedsRelaxation so that the decision on whether to relax can be made per function. In this patch, only the ARM backend makes use of this information. We must also pass the MCSubtargetInfo to applyFixup because some fixups skip error checking on the assumption that relaxation has occurred, to prevent code-generation errors applyFixup must see the same MCSubtargetInfo as fixupNeedsRelaxation. Differential Revision: https://reviews.llvm.org/D44928 llvm-svn: 334078 2018-06-05T10:00:56+00:00 Peter Smith peter.smith@linaro.org 2018-06-05T10:00:56+00:00 urn:sha1:ef945b2240b6ade6e2549c751728983ad67c396b When the branch target of a Thumb2 unconditional or conditonal branch is resolved at assembly time, no range checking is performed on the result leading to incorrect immediates. This change adds a range check: +- 16 Megabytes for unconditional branches, +- 1 Megabyte for the conditional branch. Differential Revision: https://reviews.llvm.org/D46306 llvm-svn: 333997 2018-06-05T09:32:28+00:00 Peter Smith peter.smith@linaro.org 2018-06-05T09:32:28+00:00 urn:sha1:0aafe0cee5e52135f6dc85b06210a265c619955d The Thumb BL range is + or - either 16 Megabytes or 4 Megabytes depending on whether the CPU supports Thumb2 or the v8-m baseline ops. The existing check for BL range is incorrectly set at +- 32 Megabytes. This change corrects the higher range and uses the lower range if the featurebits don't have the necessary support for it. Differential Revision: https://reviews.llvm.org/D46305 llvm-svn: 333991 2018-05-21T19:20:29+00:00 Peter Collingbourne peter@pcc.me.uk 2018-05-21T19:20:29+00:00 urn:sha1:dcd7d6c33112db3618798c1c037460cac58d7f9a With this we gain a little flexibility in how the generic object writer is created. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47045 llvm-svn: 332868 2018-05-21T17:57:19+00:00 Peter Collingbourne peter@pcc.me.uk 2018-05-21T17:57:19+00:00 urn:sha1:571a3301aeaaddcb1d784d8f27957170fe0cfd15 To make this work I needed to add an endianness field to MCAsmBackend so that writeNopData() implementations know which endianness to use. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47035 llvm-svn: 332857