summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Add a quick hack so clang does not use mul type instructions on mips.meklort-10.0.0Evan Lojewski2020-03-291-15/+36
|
* [EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)Sanjay Patel2020-03-191-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags. ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE. Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs: /// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely. (And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines. I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk. Differential Revision: https://reviews.llvm.org/D74285 (cherry picked from commit b8ebc11f032032c7ca449f020a1fe40346e707c8)
* [Clang][Driver] In -fintegrated-cc1 mode, avoid crashing on exit after a ↵Alexandre Ganea2020-03-131-0/+4
| | | | | | | | | | | | compiler crash After a crash catched by the CrashRecoveryContext, this patch prevents from accessing dangling pointers in TimerGroup structures before the clang tool exits. Previously, the default TimerGroup had internal linked lists which were still pointing to old Timer or TimerGroup instances, which lived in stack frames released by the CrashRecoveryContext. Fixes PR45164. Differential Revision: https://reviews.llvm.org/D76099 (cherry picked from commit 28ad9fc20823678881baa0d723834b88ea9e8e3a)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-033-29/+8
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* [WinEH] Fix inttoptr+phi optimization in presence of catchswitchReid Kleckner2020-03-021-4/+14
| | | | | | | | | | | | | | getFirstInsertionPt's return value must be checked for validity before casting it to Instruction*. Don't attempt to insert casts after a phi in a catchswitch block. Fixes PR45033, introduced in D37832. Reviewed By: davidxl, hfinkel Differential Revision: https://reviews.llvm.org/D75381 (cherry picked from commit 1adbe86d87bd4ecffc73ab17c7da56f44816f424)
* Attempt to fix ZLIB CMake logic on WindowsReid Kleckner2020-03-021-2/+4
| | | | | | CMake doesn't seem to like it when you regex search for "^". (cherry picked from commit 1079c68aa0fdb14d270a31c0df49a2afc5ed2485)
* [CMake] Link against ZLIB::ZLIBPetr Hosek2020-03-021-3/+22
| | | | | | | | This is the imported target that find_package(ZLIB) defines. Differential Revision: https://reviews.llvm.org/D74176 (cherry picked from commit 2181bf40d87165ff4c208b46b135be823eef5c55)
* Try to fix WindowsManifest CMake logic on WindowsReid Kleckner2020-03-021-2/+4
| | | | | | | CMake is complaining about the "^" regex if the prefixes are empty strings. (cherry picked from commit e441a584f3f7d743ab77031a47d9ad60ee56b53d)
* build: process the libxml2 library path for embeddingSaleem Abdulrasool2020-02-281-1/+10
| | | | | | | | | | | | | | | | | | | | | | Process the path for libxml2 before embedding that into the command line that is generated in `llvm-config`. Each element in the path is being given a `-l` unconditionally which should not be the case for absolute paths. Since the library path may be absolute or not, just apply some CMake pre-processing when generating the path. Before: ``` /usr/lib/x86_64-linux-gnu/libz.so -lrt -ldl -ltinfo -lpthread -lm /usr/lib/x86_64-linux-gnu/libxml2.so ``` After: ``` /usr/lib/x86_64-linux-gnu/libz.so -lrt -ldl -ltinfo -lpthread -lm -lxml2 ``` Resolves PR44179! (cherry picked from commit c3595d1069277b4ab0df49d7139b6f1bbc94f21c)
* No longer generate calls to *_finiteserge-sans-paille2020-02-282-61/+15
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* SROA: Don't drop atomic load/store alignments (PR45010)Hans Wennborg2020-02-281-0/+4
| | | | | | | | | | | | | SROA will drop the explicit alignment on allocas when the ABI guarantees enough alignment. Because the alignment on new load/store instructions are set based on the alloca's alignment, that means SROA would end up dropping the alignment from atomic loads and stores, which is not allowed (see bug). For those, make sure to always carry over the alignment from the previous instruction. Differential revision: https://reviews.llvm.org/D75266 (cherry picked from commit d48c981697a49653efff9dd14fa692d99e6fa868)
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-2814-256/+13
| | | | | | | | | | | | | | | | llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* [InstCombine] foldShiftIntoShiftInAnotherHandOfAndInICmp(): fix miscompile ↵Roman Lebedev2020-02-271-1/+19
| | | | | | | | | | | | | | | | | | | | | (PR44802) Much like with reassociateShiftAmtsOfTwoSameDirectionShifts(), as input, we have the following pattern: icmp eq/ne (and ((x shift Q), (y oppositeshift K))), 0 We want to rewrite that as: icmp eq/ne (and (x shift (Q+K)), y), 0 iff (Q+K) u< bitwidth(x) While we know that originally (Q+K) would not overflow (because 2 * (N-1) u<= iN -1), we may have looked past extensions of shift amounts. so it may now overflow in smaller bitwidth. To ensure that does not happen, we need to ensure that the total maximal shift amount is still representable in that smaller bitwidth. If the overflow would happen, (Q+K) u< bitwidth(x) check would be bogus. https://bugs.llvm.org/show_bug.cgi?id=44802 (cherry picked from commit 2855c8fed9326ec44526767f1596a4fe4e55dc70)
* [InstCombine] reassociateShiftAmtsOfTwoSameDirectionShifts(): fix miscompile ↵Roman Lebedev2020-02-271-2/+22
| | | | | | | | | | | | | | | | | | | (PR44802) As input, we have the following pattern: Sh0 (Sh1 X, Q), K We want to rewrite that as: Sh x, (Q+K) iff (Q+K) u< bitwidth(x) While we know that originally (Q+K) would not overflow (because 2 * (N-1) u<= iN -1), we may have looked past extensions of shift amounts. so it may now overflow in smaller bitwidth. To ensure that does not happen, we need to ensure that the total maximal shift amount is still representable in that smaller bitwidth. If the overflow would happen, (Q+K) u< bitwidth(x) check would be bogus. https://bugs.llvm.org/show_bug.cgi?id=44802 (cherry picked from commit 781d077afb0ed9771c513d064c40170c1ccd21c9)
* [MC][ARM] Resolve some pcrel fixups at assembly time (PR44929)Hans Wennborg2020-02-272-14/+14
| | | | | | | | | | | | 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)
* [MemorySSA] Don't verify MemorySSA unless VerifyMemorySSA enabledNikita Popov2020-02-271-1/+4
| | | | | | | | | | | MemorySSA is often taking up an unreasonable fraction of runtime in assertion enabled builds. Turns out that there is one code-path that runs verifyMemorySSA() even if VerifyMemorySSA is not enabled. This patch makes it conditional as well. Differential Revision: https://reviews.llvm.org/D74505 (cherry picked from commit f0b57d8071853ec2ab459c0492854c67ea4fa93c)
* Revert "[LICM] Support hosting of dynamic allocas out of loops"Philip Reames2020-02-261-45/+0
| | | | | | | | This reverts commit 8d22100f66c4170510c6ff028c60672acfe1cff9. There was a functional regression reported (https://bugs.llvm.org/show_bug.cgi?id=44996). I'm not actually sure the patch is wrong, but I don't have time to investigate currently, and this line of work isn't something I'm likely to get back to quickly. (cherry picked from commit 14845b2c459021e3dbf2ead52d707d4a7db40cbb)
* [Codegen] Revert rL354676/rL354677 and followups - introduced PR43446 miscompileRoman Lebedev2020-02-261-27/+0
| | | | | | | | | | 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)
* [LoopRotate] Get and update MSSA only if available in legacy pass manager.Alina Sbirlea2020-02-261-5/+6
| | | | | | | | | | | | | | | | | | | | | Summary: Potential fix for: https://bugs.llvm.org/show_bug.cgi?id=44889 and https://bugs.llvm.org/show_bug.cgi?id=44408 In the legacy pass manager, loop rotate need not compute MemorySSA when not being in the same loop pass manager with other loop passes. There isn't currently a way to differentiate between the two cases, so this attempts to limit the usage in LoopRotate to only update MemorySSA when the analysis is already available. The side-effect of this is that it will split the Loop pipeline. This issue does not apply to the new pass manager, where we have a flag specifying if all loop passes in that loop pass manager preserve MemorySSA. Reviewers: dmgreen, fedor.sergeev, nikic Subscribers: Prazek, hiraditya, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74574 (cherry picked from commit 1326a5a4cfe004181f2ec8231d84ecda2b93cb25)
* Don't generate libcalls for wide shift on Windows ARM (PR42711)Hans Wennborg2020-02-251-1/+1
| | | | | | | The previous patch (cff90f07cb5cc3c3bc58277926103af31caef308) didn't cover ARM. (cherry picked from commit decd021facba804b57e8d80b6159c987d3261ab8)
* Filter callbr insts from critical edge splittingBill Wendling2020-02-212-2/+4
| | | | | | | | Similarly to how splitting predecessors with an indirectbr isn't handled in the generic way, we also shouldn't split callbrs, for similar reasons. (cherry picked from commit 2fe457690da0fc38bc7f9f1d0aee2ba6a6a16ada)
* [RISCV] Correct the CallPreservedMask for the function call in an interrupt ↵Shiva Chen2020-02-201-7/+0
| | | | | | | | | | | handler CallPreservedMask is used to describe the register liveness after a function call. The function call in an interrupt handler should use the same CallPreservedMask as normal functions. So that only callee save registers can live through the function call. (cherry picked from commit 1cae2f9d192c69833e22684ca338660942ab464e)
* Fix unused function warning (PR44808)Hans Wennborg2020-02-191-5/+7
| | | | (cherry picked from commit a19de32095e4cdb18957e66609574ce2021a8d1c)
* [X86CmovConversion] Make heuristic for optimized cmov depth more ↵Nikita Popov2020-02-191-6/+7
| | | | | | | | | | | | | | | | | | | conservative (PR44539) Fix/workaround for https://bugs.llvm.org/show_bug.cgi?id=44539. As discussed there, this pass makes some overly optimistic assumptions, as it does not have access to actual branch weights. This patch makes the computation of the depth of the optimized cmov more conservative, by assuming a distribution of 75/25 rather than 50/50 and placing the weights to get the more conservative result (larger depth). The fully conservative choice would be std::max(TrueOpDepth, FalseOpDepth), but that would break at least one existing test (which may or may not be an issue in practice). Differential Revision: https://reviews.llvm.org/D74155 (cherry picked from commit 5eb19bf4a2b0c29a8d4d48dfb0276f096eff9bec)
* [SLPVectorizer] Do not assume extracelement idx is a ConstantInt.Florian Hahn2020-02-191-6/+5
| | | | | | | | | | | | | | | | | | The index of an ExtractElementInst is not guaranteed to be a ConstantInt. It can be any integer value. Check explicitly for ConstantInts. The new test cases illustrate scenarios where we crash without this patch. I've also added another test case to check the matching of extractelement vector ops works. Reviewers: RKSimon, ABataev, dtemirbulatov, vporpo Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D74758 (cherry picked from commit e32522ca178acc42e26f21d64ef8fc180ad772bd)
* [FPEnv][ARM] Don't call mutateStrictFPToFP when loweringJohn Brawn2020-02-181-2/+10
| | | | | | | | | | | | mutateStrictFPToFP can delete the node and replace it with another with the same value which can later cause problems, and returning the result of mutateStrictFPToFP doesn't work because SelectionDAGLegalize expects that the returned value has the same number of results as the original. Instead handle things by doing the mutation manually. Differential Revision: https://reviews.llvm.org/D74726 (cherry picked from commit 594a89f7270da74c89f2321432bc6a7135773fa5)
* [AArch64][FPenv] Update chain of int to fp conversionDiogo Sampaio2020-02-181-2/+8
| | | | | | | | | | | | | | | | | | | 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)
* [ARM] Fix infinite loop when lowering STRICT_FP_EXTENDJohn Brawn2020-02-181-0/+9
| | | | | | | | | | | | | | | | If the target has FP64 but not FP16 then we have custom lowering for FP_EXTEND and STRICT_FP_EXTEND with type f64. However if the extend is from f32 to f64 the current implementation will cause in infinite loop for STRICT_FP_EXTEND due to emitting a merge_values of the original node which after replacement becomes a merge_values of itself. Fix this by not doing anything for f32 to f64 extend when we have FP64, though for STRICT_FP_EXTEND we have to do the strict-to-nonstrict mutation as that doesn't happen automatically for opcodes with custom lowering. Differential Revision: https://reviews.llvm.org/D74559 (cherry picked from commit 0ec57972967dfb43fc022c2e3788be041d1db730)
* [FPEnv][AArch64] Add lowering of f128 STRICT_FSETCCJohn Brawn2020-02-181-2/+4
| | | | | | | | These get lowered to function calls, like the non-strict versions. Differential Revision: https://reviews.llvm.org/D73784 (cherry picked from commit 68cf574857c81f711f498a479855a17e7bea40f7)
* [FPEnv][ARM] Add lowering of STRICT_FSETCC and STRICT_FSETCCSJohn Brawn2020-02-183-10/+75
| | | | | | | | | | | | | | | These can be lowered to code sequences using CMPFP and CMPFPE which then get selected to VCMP and VCMPE. The implementation isn't fully correct, as the chain operand isn't handled correctly, but resolving that looks like it would involve changes around FPSCR-handling instructions and how the FPSCR is modelled. The fp-intrinsics test was already testing some of this but as the entire test was being XFAILed it wasn't noticed. Un-XFAIL the test and instead leave the cases where we aren't generating the right instruction sequences as FIXME. Differential Revision: https://reviews.llvm.org/D73194 (cherry picked from commit b37d59353f699e99f139a9227a6a69964ef4b132)
* [FPEnv][AArch64] Add lowering and instruction selection for strict conversionsJohn Brawn2020-02-182-24/+54
| | | | | | | | | | Strict fp-to-int and int-to-fp conversions can be handled in the same way that the non-strict versions are (by using the appropriate instruction or converting to a function call when we have no instruction). Differential Revision: https://reviews.llvm.org/D73625 (cherry picked from commit 0bb9a27c9895c0fbc3f55f56ad7f1e1927398fce)
* [FPEnv][AArch64] Add lowering and instruction selection for STRICT_FP_ROUNDJohn Brawn2020-02-182-8/+16
| | | | | | | | | | This gets selected to the appropriate fcvt instruction. Handling from there on isn't fully correct yet, as we need to model fcvt reading and writing to fpsr and fpcr. Differential Revision: https://reviews.llvm.org/D73201 (cherry picked from commit 258d8dd76afd88a12539b182a53ff21dcba16a2d)
* Add lowering of STRICT_FSETCC and STRICT_FSETCCSJohn Brawn2020-02-183-11/+57
| | | | | | | | | | These become STRICT_FCMP and STRICT_FCMPE, which then get selected to the corresponding FCMP and FCMPE instructions, though the handling from there on isn't fully correct as we don't model reads and writes to FPCR and FPSR. Differential Revision: https://reviews.llvm.org/D73368 (cherry picked from commit 2224407ef5baf6100fa22420feb4d25af1a9493f)
* [CodeGen] Fix the computation of the alignment of split stores.Hans Wennborg2020-02-121-2/+10
| | | | | | By Clement Courbet! Backported from rG15488ff24b4a
* Fix an unused variable warningHans Wennborg2020-02-121-1/+1
| | | | (cherry picked from commit ea9850b6c71d975935de15bd4128508b260165c5)
* Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field"Jeremy Morse2020-02-126-51/+54
| | | | | | | | | | | | | | | | | | | | | | | 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)
* Revert "[DebugInfo][DAG] Distinguish different kinds of location indirection"Jeremy Morse2020-02-121-19/+5
| | | | | | | | | | | | | | 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)
* [DebugInfo] Re-instate LiveDebugVariables scope trimmingJeremy Morse2020-02-121-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Fix MSVC build with C++ EH enabledReid Kleckner2020-02-121-1/+1
| | | | | | | | | | | | | | | | | Mark the CrashRecoveryContextImpl constructor noexcept, so that MSVC won't emit an unwind helper to clean up the allocation from `new` if the constructor throws an exception. Otherwise, MSVC complains: llvm\lib\Support\CrashRecoveryContext.cpp(220): error C2712: \ Cannot use __try in functions that require object unwinding The other simple fix would be to wrap `new` in a static helper or lambda. Users have reported that Tensorflow builds LLVM with /EHsc. (cherry picked from commit a349c09162a8260bdf691c4f7ab72a16c33975f6)
* [SystemZ] Bugfix in emitSelect()Jonas Paulsson2020-02-121-2/+3
| | | | | | | | | | | | | | When more than one SelectPseudo instruction is handled a new MBB is returned. This must not be done if that would result in leaving an undhandled isel pseudo behind in the original MBB. Fixes https://bugs.llvm.org/show_bug.cgi?id=44849. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D74352 (cherry picked from commit 0311e28e9cc01a244faa774b8cab337b45404fa9)
* [Clang][Driver] After default -fintegrated-cc1, make ↵Alexandre Ganea2020-02-123-7/+36
| | | | | | | | | | | | | llvm::report_fatal_error() generate preprocessed source + reproducer.sh again. Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue. Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise. Fixes PR44705. Differential Revision: https://reviews.llvm.org/D73742 (cherry picked from commit faace365088a2a3a4cb1050a9facfc34a7a56577)
* [Support] Don't modify the current EH context during stack unwindingReid Kleckner2020-02-111-1/+7
| | | | | | | | | | | | | Copy it instead. Otherwise, key registers (such as RBP) may get zeroed out by the stack unwinder. Fixes CrashRecoveryTest.DumpStackCleanup with MSVC in release builds. Reviewed By: stella.stamenova Differential Revision: https://reviews.llvm.org/D73809 (cherry picked from commit b074acb82f7e75a189fa7933b09627241b166121)
* IR Linking: Support merging Warning+Max module metadata flagsDavid Blaikie2020-02-111-23/+47
| | | | | | | | | | | | | | | | | Summary: Debug Info Version was changed to use "Max" instead of "Warning" per the original design intent - but this maxes old/new IR unlinkable, since mismatched merge styles are a linking failure. It seems possible/maybe reasonable to actually support the combination of these two flags: Warn, but then use the maximum value rather than the first value/earlier module's value. Reviewers: tejohnson Differential Revision: https://reviews.llvm.org/D74257 (cherry picked from commit ba9cae58bbdd41451ee67773c9d0f90a01756f12)
* [Support] When using SEH, create a impl instance for CrashRecoveryContext. NFCI.Alexandre Ganea2020-02-101-25/+35
| | | | | | | | | | Previously, the SEH codepath in CrashRecoveryContext didn't create a CrashRecoveryContextImpl. The other codepaths (VEH and Unix) were creating it. When running with -fintegrated-cc1, this is needed to handle exit() as a jump to CrashRecoveryContext's exception filter, through a call to RaiseException. In that situation, we need a user-defined exception code, which is later interpreted as an exit() by the exception filter. This in turn needs to set RetCode accordingly, *inside* the exception filter, and *before* calling HandleCrash(). Differential Revision: https://reviews.llvm.org/D74078 (cherry picked from commit 2a3fa0fc5cd7d3398c0293915b0e569eaa0be24b)
* [Clang] Remove unused #pragma clang __debug handle_crashAlexandre Ganea2020-02-101-8/+0
| | | | | | | | | As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash). Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar. Differential Revision: https://reviews.llvm.org/D74063 (cherry picked from commit 8ecde3ac34bbb5a8d53d8ec5cd32867658646df1)
* [AArch64] Add option to enable/disable load-store renaming.Florian Hahn2020-02-101-0/+7
| | | | | | | | This patch adds a new option to enable/disable register renaming in the load-store optimizer. Defaults to disabled, as there is a potential mis-compile caused by this. (cherry picked from commit 8e3f59b45ae185cc9b4e3a817d7ac958f1d55976)
* AMDGPU/EG,CM: Implement fsqrt using recip(rsqrt(x)) instead of x * rsqrt(x)Jan Vesely2020-02-103-4/+10
| | | | | | | | | | | | The old version might be faster on EG (RECIP_IEEE is Trans only), but it'd need extra corner case checks. This gives correct corner case behaviour and saves a register. Fixes OCL CTS sqrt test (1-thread, scalar) on Turks. Reviewer: arsenm Differential Revision: https://reviews.llvm.org/D74017 (cherry picked from commit e6686adf8a743564f0c455c34f04752ab08cf642)
* [X86] Use MVT::i8 instead of MVT::i64 for shift amount in BuildSDIVPow2Craig Topper2020-02-101-1/+1
| | | | | | | | | | | | X86 uses i8 for shift amounts. This code can fail on a 32-bit target if it runs after type legalization. This code was copied from AArch64 and modified for X86, but the shift amount wasn't changed to the correct type for X86. Fixes PR44812 (cherry picked from commit ec9a94af4d5fb3270f2451fcbec5a3a99f4ac03a)
* [BPF] disable ReduceLoadWidth during SelectionDag phaseYonghong Song2020-02-101-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The compiler may transform the following code ctx = ctx + reloc_offset ... (*(u32 *)ctx) & 0x8000 ... to ctx = ctx + reloc_offset ... (*(u8 *)(ctx + 1)) & 0x80 ... where reloc_offset will be replaced with a constant during AsmPrinter phase. The above transformed code will be rejected the kernel verifier as it does not allow *(type *)((ctx + non_zero_offset1) + non_zero_offset2) style access pattern. It is hard at SelectionDag phase to identify whether a load is related to context or not. Sometime, interprocedure analysis may be needed. So let us simply prevent such optimization from happening. Differential Revision: https://reviews.llvm.org/D73997 (cherry picked from commit d96c1bbaa03574daf759e5e9a6c75047c5e3af64)
* [ARM] Fix non-determenistic behaviourDiogo Sampaio2020-02-101-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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)
OpenPOWER on IntegriCloud