Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-24T18:38:40+00:00 2020-01-24T18:38:40+00:00 Fangrui Song maskray@google.com 2020-01-20T22:57:11+00:00 urn:sha1:bf04730dee1b74c8e7661c671484eff93c1f5a77 Similar to the function attribute `prefix` (prefix data), "patchable-function-prefix" inserts data (M NOPs) before the function entry label. -fpatchable-function-entry=2,1 (1 NOP before entry, 1 NOP after entry) will look like: ``` .type foo,@function .Ltmp0: # @foo nop foo: .Lfunc_begin0: # optional `bti c` (AArch64 Branch Target Identification) or # `endbr64` (Intel Indirect Branch Tracking) nop .section __patchable_function_entries,"awo",@progbits,get,unique,0 .p2align 3 .quad .Ltmp0 ``` -fpatchable-function-entry=N,0 + -mbranch-protection=bti/-fcf-protection=branch has two reasonable placements (https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01185.html): ``` (a) (b) func: func: .Ltmp0: bti c bti c .Ltmp0: nop nop ``` (a) needs no additional code. If the consensus is to go for (b), we will need more code in AArch64BranchTargets.cpp / X86IndirectBranchTracking.cpp . Differential Revision: https://reviews.llvm.org/D73070 (cherry picked from commit 22467e259507f5ead2a87d989251b4c951a587e4) 2019-09-03T11:30:54+00:00 David Green david.green@arm.com 2019-09-03T11:30:54+00:00 urn:sha1:2f3574c16894f87dd797b8962babb4a766503279 The code here seems to date back to r134705, when tablegen lowering was first being added. I don't believe that we need to include CPSR implicit operands on the MCInst. This now works more like other backends (like AArch64), where all implicit registers are skipped. This allows the AliasInst for CSEL's to match correctly, as can be seen in the test changes. Differential revision: https://reviews.llvm.org/D66703 llvm-svn: 370745 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2017-07-17T13:15:26+00:00 Javed Absar javed.absar@arm.com 2017-07-17T13:15:26+00:00 urn:sha1:dd2c29ef8374b358d4f1ff55904da9aed941cbd7 Convert iteration over operands to range-loop. Reviewed by: @rovka, @echristo Differential Revision: https://reviews.llvm.org/D35419 llvm-svn: 308173 2017-06-06T11:49:48+00:00 Chandler Carruth chandlerc@gmail.com 2017-06-06T11:49:48+00:00 urn:sha1:6bda14b3137a58c42220b209d18691ef87f0d845 I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787 2017-04-21T21:48:41+00:00 Hans Wennborg hans@hanshq.net 2017-04-21T21:48:41+00:00 urn:sha1:9b9a5358dd35d63f83a54256aaf44e0c3cffdde2 In addition to the original commit, tighten the condition for when to pad empty functions to COFF Windows. This avoids running into problems when targeting e.g. Win32 AMDGPU, which caused test failures when this was committed initially. llvm-svn: 301047 2017-04-21T21:10:37+00:00 Hans Wennborg hans@hanshq.net 2017-04-21T21:10:37+00:00 urn:sha1:04593000d871943ca37efa1ace6e63c401d633bf This broke almost all bots. Reverting while fixing. llvm-svn: 301041 2017-04-21T20:58:12+00:00 Hans Wennborg hans@hanshq.net 2017-04-21T20:58:12+00:00 urn:sha1:cb3e81071495dd2f63af38f6b50945a47939f9d7 Empty functions can lead to duplicate entries in the Guard CF Function Table of a binary due to multiple functions sharing the same RVA, causing the kernel to refuse to load that binary. We had a terrific bug due to this in Chromium. It turns out we were already doing this for Mach-O in certain situations. This patch expands the code for that in AsmPrinter::EmitFunctionBody() and renames TargetInstrInfo::getNoopForMachoTarget() to simply getNoop() since it seems it was used for not just Mach-O anyway. Differential Revision: https://reviews.llvm.org/D32330 llvm-svn: 301040 2017-02-07T13:07:12+00:00 Christof Douma Christof.Douma@arm.com 2017-02-07T13:07:12+00:00 urn:sha1:d3ed8380e08e51535a32b30df2e68dac6a08a848 When constructing global address literals while targeting the RWPI relocation model. LLVM currently only uses literal pools. If MOVW/MOVT instructions are available we can use these instead. Beside being more efficient it allows -arm-execute-only to work with -relocation-model=RWPI as well. When we generate MOVW/MOVT for global addresses when targeting the RWPI relocation model, we need to use base relative relocations. This patch does the needed plumbing in MC to generate these for MOVW/MOVT. Differential Revision: https://reviews.llvm.org/D29487 Change-Id: I446786e43a6f5aa9b6a5bb2cd216d60d41c7755d llvm-svn: 294298 2017-01-26T23:40:06+00:00 Eugene Zelenko eugene.zelenko@gmail.com 2017-01-26T23:40:06+00:00 urn:sha1:e6cf4374b03678aab59c17a562b409ece372ff3c llvm-svn: 293229