Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2020-02-28T10:52:11+00:00 2020-02-28T10:52:11+00:00 serge-sans-paille sguelton@redhat.com 2020-02-21T14:51:19+00:00 urn:sha1:cd0926d087a85c5ee1222ca80980b4440214a822 According to Joseph Myers, a libm maintainer > They were only ever an ABI (selected by use of -ffinite-math-only or > options implying it, which resulted in the headers using "asm" to redirect > calls to some libm functions), not an API. The change means that ABI has > turned into compat symbols (only available for existing binaries, not for > anything newly linked, not included in static libm at all, not included in > shared libm for future glibc ports such as RV32), so, yes, in any case > where tools generate direct calls to those functions (rather than just > following the "asm" annotations on function declarations in the headers), > they need to stop doing so. As a consequence, we should no longer assume these symbols are available on the target system. Still keep the TargetLibraryInfo for constant folding. Differential Revision: https://reviews.llvm.org/D74712 (cherry picked from commit 6d15c4deab51498b70825fb6cefbbfe8f3d9bdcf) For https://bugs.llvm.org/show_bug.cgi?id=45034 2020-02-26T14:22:28+00:00 Roman Lebedev lebedev.ri@gmail.com 2020-02-25T17:08:58+00:00 urn:sha1:3abd9cd486d9c45867458f64d1294db698c39b4e This reverts https://reviews.llvm.org/D58468 (rL354676, 44037d7a6377ec8e5542cced73583283334b516b), and all and any follow-ups to that code block. https://bugs.llvm.org/show_bug.cgi?id=43446 (cherry picked from commit d20907d1de89bf63b589fadd8c096d4895e47fba) 2020-02-18T15:46:44+00:00 Diogo Sampaio diogo.sampaio@arm.com 2020-02-15T05:05:15+00:00 urn:sha1:b5d9a7e72fafaead89f0cc8994925c90ed3169be Summary: When using strict fp, it is required to update the chain when performing integer type promotion of a operand to a integer to floating point conversion. Reviewers: craig.topper, john.brawn Reviewed By: craig.topper Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74597 (cherry picked from commit 8bc790f9e6a6fc6d8fe8f41a7120269366fa0957) 2020-02-12T14:29:31+00:00 Hans Wennborg hans@chromium.org 2020-02-12T14:27:11+00:00 urn:sha1:b3cf70427eb1e97d9b89ba6e9298c280c8a32c74 By Clement Courbet! Backported from rG15488ff24b4a 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-12T13:06:19+00:00 Jeremy Morse jeremy.morse@sony.com 2020-02-05T16:57:59+00:00 urn:sha1:04d7337d69fa38f00179811419207a9ef5eef83e This reverts commit 3137fe4d23eeb8df08c03e9111465325eeafe08e. I'm backing out D68945, which this patch is a follow up for. It'll be re-landed when D68945 is fixed. The changes to dbg-value-func-arg.ll occur because our handling of certain kinds of location now mixes up indirection that happens at different points in a DIExpression. While this is a regression, it's a return to the prior behaviour while a better patch is sought. (cherry picked from commit ece761427f63de96ee52bbd6be1c61b07967a917) 2020-02-12T13:04:24+00:00 Jeremy Morse jeremy.morse@sony.com 2020-02-04T14:19:42+00:00 urn:sha1:c1701728b93b3aec39d3b93d0182648887edfdb1 This patch reverts part of r362750 / D62650, which stopped LiveDebugVariables from trimming leading variable location ranges down to only covering those instructions that are in scope. I've observed some circumstances where the number of DBG_VALUEs in a function can be amplified in an un-necessary way, to cover more instructions that are out of scope, leading to very slow compile times. Trimming the range of instructions that the variables cover solves the slow compile times. The specific problem that r362750 tries to fix is addressed by the assignment to RStart that I've added. Any variable location that begins at the first instruction of a block will now be considered to begin at the start of the block. While these sound the same, the have different SlotIndexes, and the register allocator may shoehorn additional instructions in between the two. The test added in the past (wrong_debug_loc_after_regalloc.ll) still works with this modification. live-debug-variables.ll has a range trimmed to not cover the prologue of the function, while dbg-addr-dse.ll has a DBG_VALUE sink past one instruction with no DebugLoc, which is expected behaviour. Differential Revision: https://reviews.llvm.org/D73691 (cherry picked from commit 41206b61e30c3d84188cb17b91c2c0c800982dd1) 2020-02-10T12:27:45+00:00 Diogo Sampaio diogo.sampaio@arm.com 2020-02-06T08:54:30+00:00 urn:sha1:a124bebdd5ff5cf49480956258c322ed9204943c Summary: ARM Type Promotion pass does not clear the container that defines if one variable was visited or not, missing optimization opportunities by luck when two llvm:Values from different functions are allocated at the same memory address. Also fixes a comment and uses existing method to pop and obtain last element of the worklist. Reviewers: samparker Reviewed By: samparker Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73970 (cherry picked from commit 8ba2b6281075c65c1a47abed57810e1201942533) 2020-02-05T12:53:24+00:00 David Green david.green@arm.com 2020-02-04T09:25:01+00:00 urn:sha1:8195a96595baca8c0141de2a121dcf3f8c0ea616 Under MVE, we do not have any lowering for fminimum, which a vector_reduce_fmin without NoNan will be expanded into. As with the other recent patches, force this to expand in the pre-isel pass. Note that Neon lowering would be OK because the scalar fminimum uses the vector VMIN instruction, but is probably better to just rely on the scalar operations, which is what is done here. Also fixes what appears to be the reversal of INF vs -INF in the vector_reduce_fmin widening code. (cherry picked from commit 362d00e0510ee75750499e2993a782428e377215) 2020-02-03T12:57:25+00:00 Fangrui Song maskray@google.com 2020-01-30T02:00:57+00:00 urn:sha1:cbd4815dec165fc4190f30cd6f409334c7e59063 Summary: For -fpatchable-function-entry=N,0 -mbranch-protection=bti, after 9a24488cb67a90f889529987275c5e411ce01dda, we place the NOP sled after the initial BTI. ``` .Lfunc_begin0: bti c nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lfunc_begin0 ``` This patch adds a label after the initial BTI and changes the __patchable_function_entries entry to reference the label: ``` .Lfunc_begin0: bti c .Lpatch0: nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lpatch0 ``` This placement is compatible with the resolution in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 . A local linkage function whose address is not taken does not need a BTI. Placing the patch label after BTI has the advantage that code does not need to differentiate whether the function has an initial BTI. Reviewers: mrutland, nickdesaulniers, nsz, ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73680 (cherry picked from commit 06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac)