summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [LLVM][NFC] remove unused fieldsGuillaume Chatelet2019-08-231-2/+0
| | | | | | | | | | | | | | | | | | | Summary: Here is the commit introducing the fields https://github.com/llvm/llvm-project/commit/cf6749e4c091 It dates back from 2006 and was used by AArch64 backend. There is no more reference to these fields in the whole codebase so I think it's fine. Reviewers: courbet Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66683 llvm-svn: 369810
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-0/+1
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-235-100/+339
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [AArch64][GlobalISel] Import XRO load/store patterns instead of custom selectionJessica Paquette2019-08-232-66/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using custom C++ in `earlySelect` for loads and stores, just import the patterns. Remove `earlySelectLoad`, since we can just import the work it's doing. Some minor changes to how `ComplexRendererFns` are returned for the XRO addressing modes. If you add immediates in two steps, sometimes they are not imported properly and you only end up with one immediate. I'm not sure if this is intentional. - Update load-addressing-modes.mir to include the instructions we can now import. - Add a similar test, store-addressing-modes.mir to show which store opcodes we currently import, and show that we can pull in shifts etc. - Update arm64-fastisel-gep-promote-before-add.ll to use FastISel instead of GISel. This test failed with GISel because GISel folds the gep into the load. The test checks that FastISel doesn't fold non-pointer-width adds into loads. GISel on the other hand, produces a G_CONSTANT of -128 for the add, and then a G_GEP, which must be pointer-width. Note that we don't get STRBRoX right now. It seems like the importer can't handle `FPR8Op:{ *:[Untyped] }:$Rt` source operands. So, those are not currently supported. Differential Revision: https://reviews.llvm.org/D66679 llvm-svn: 369806
* [GlobalISel] Legalizer: Retry combining illegal artifacts as long as there ↵Volkan Keles2019-08-231-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | new artifacts Summary: Currently, Legalizer aborts if it’s unable to legalize artifacts. However, it’s possible to combine them after processing the rest of the instruction because the legalization is likely to generate more artifacts that allow ArtifactCombiner to combine away them. Instead, move illegal artifacts to another list called RetryList and wait until all of the instruction in InstList are legalized. After that, check if there is any new artifacts and try to combine them again if that’s the case. If not, abort. The idea is similar to D59339, but the approach is a bit different. This patch fixes the issue described above, but the legalizer still may be unable to handle some cases depending on when to legalize artifacts. So, in the long run, we probably need a different legalization strategy that handles this dependency in a better way. Reviewers: dsanders, aditya_nandakumar, qcolombet, arsenm, aemerson, paquette Reviewed By: dsanders Subscribers: jvesely, wdng, nhaehnle, rovka, javed.absar, hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65894 llvm-svn: 369805
* [Attributor] Manifest alignment in load and store instructionsJohannes Doerfert2019-08-231-0/+50
| | | | | | | | | | | | | | | | Summary: We can now manifest alignment information in load/store instructions if the pointer is known to have a better alignment. Reviewers: uenoku, sstefan1, lebedev.ri Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66567 llvm-svn: 369804
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-2316-33/+39
| | | | llvm-svn: 369803
* [X86] Move a transform out of combineConcatVectorOps so we don't prematurely ↵Craig Topper2019-08-231-9/+13
| | | | | | | | | | | | turn CONCAT_VECTORS into INSERT_SUBVECTORS. CONCAT_VECTORS and INSERT_SUBVECTORS can both call combineConcatVectorOps, but we shouldn't produce INSERT_SUBVECTORS from there. We should keep CONCAT_VECTORS until vector legalization. Noticed while looking at the madd_quad_reduction test from madd.ll llvm-svn: 369802
* [SampleFDO] Add ExtBinary format to support extension of binary profile.Wei Mi2019-08-232-29/+258
| | | | | | | | | | | | This is a patch split from https://reviews.llvm.org/D66374. It tries to add a new format of profile called ExtBinary. The format adds a section header table to the profile and organize the profile in sections, so the future extension like adding a new section or extending an existing section will be easier while keeping backward compatiblity feasible. Differential Revision: https://reviews.llvm.org/D66513 llvm-svn: 369798
* [PowerPC] Expand v1i128 sminRoland Froese2019-08-231-4/+12
| | | | | | | | | The smin opcode and friends for v1i128 are incorrectly marked as legal for PPC. Change them to expand. Differential Revision: https://reviews.llvm.org/D64960 llvm-svn: 369797
* Fix a bug in just submitted rL369789Philip Reames2019-08-231-1/+4
| | | | | | | | Started implementing the vector case and realized the scalar case hadn't handled the GEP producing a different type than the base correctly. It's entertaining seeing what slips through review when we're focused on the 'hard' parts. :( Also adding an extra vector test as it happened to be in workspace and wasn't worth separating. llvm-svn: 369795
* RegScavenger: Use RegisterMatt Arsenault2019-08-231-17/+17
| | | | llvm-svn: 369794
* [X86] Mark VPDPWSSD and VPDPWSSDS as commutable. Add stack folding tests.Craig Topper2019-08-232-10/+33
| | | | llvm-svn: 369792
* Revert r369233.Manoj Gupta2019-08-231-14/+10
| | | | | | | | This breaks building of some projects like libfuse and alsa-lib that now fail when linking. Error details in PR43092. llvm-svn: 369790
* [InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, nullPhilip Reames2019-08-231-0/+21
| | | | | | | | | | This generalizes the isGEPKnownNonNull rule from ValueTracking to apply when we do not know if the base is non-null, and thus need to replace one condition with another. The core notion is that since an inbounds GEP can only form null if the base pointer is null and the offset is zero. However, if the offset is non-zero, the the "inbounds" marker makes the result poison. Thus, we're free to ignore the case where the offset is non-zero. Similarly, there's no case under which a non-null base can result in a null result without generating poison. Differential Revision: https://reviews.llvm.org/D66608 llvm-svn: 369789
* [BasicAA] Use dereferenceability to reason about aliasingJohannes Doerfert2019-08-231-4/+26
| | | | | | | | | | | | | | | | | | | | | Summary: We already use the fact that an object with known size X does not alias another objection of size Y > X before. With this commit, we use dereferenceability information to determine a lower bound for Y and not only rely on the user provided query size. The result for @global_and_deref_arg_2() and @local_and_deref_ret_2() in test/Analysis/BasicAA/dereferenceable.ll improved with this patch. Reviewers: asbirlea, chandlerc, hfinkel, sanjoy Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66157 llvm-svn: 369786
* [Attributor] Manifest constant return valuesJohannes Doerfert2019-08-231-1/+25
| | | | | | | | | | | | | | | | Summary: If the unique return value is a constant we now replace call uses with that constant. Reviewers: sstefan1, uenoku Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66551 llvm-svn: 369785
* [Attributor] Deal with shrinking dereferenceability in a loopJohannes Doerfert2019-08-231-6/+17
| | | | | | | | | | | | | | | | | | Summary: If we have a loop in which the dereferenceability of a pointer decreases we did slowly decrease it iteration by iteration, leading to a timeout. With this patch we detect such circular reasoning and indicate a fixpoint early. Reviewers: uenoku, sstefan1 Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66558 llvm-svn: 369784
* Allow Compiler.h to be included in C files and fix fallthrough warningsNathan Huckleberry2019-08-231-3/+4
| | | | | | | | | | | | | | | | | | | | | Summary: Since clang does not support comment style fallthrough annotations these should be switched to macros defined in Compiler.h. This requires some fixing to Compiler.h. Original patch: https://reviews.llvm.org/D66487 Reviewers: nickdesaulniers, aaron.ballman, xbolva00, rsmith Reviewed By: nickdesaulniers, aaron.ballman, rsmith Subscribers: rsmith, sfertile, ormris, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66609 llvm-svn: 369782
* [SelectionDAG][X86] Enable iX SimplifyDemandedBits to vXi1 ↵Craig Topper2019-08-232-3/+21
| | | | | | | | | | | | | | | | SimplifyDemandedVectorElts simplification. Add a hack to X86 to avoid a regression Patch showing the effect of enabling bool vector oversimplification. Non-VLX builds can simplify a kshift shuffle, but VLX builds simplify: insert_subvector v8i zeroinitializer, v2i --> insert_subvector v8i undef, v2i Preventing the removal of the AND to clear the upper bits of result Differential Revision: https://reviews.llvm.org/D53022 llvm-svn: 369780
* [DebugInfo] Remove invalidated locations during LiveDebugValuesJeremy Morse2019-08-231-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | LiveDebugValues gives variable locations to blocks, but it should also take away. There are various circumstances where a variable location is known until a loop backedge with a different location is detected. In those circumstances, where there's no agreement on the variable location, it should be undef / removed, otherwise we end up picking a location that's valid on some loop iterations but not others. However, LiveDebugValues doesn't currently do this, see the new testcase attached. Without this patch, the location of !3 is assumed to be %bar through the loop. Once it's added to the In-Locations list, it's never removed, even though the later dbg.value(0... of !3 makes the location un-knowable. This patch checks during block-location-joining to see whether any previously-present locations have been removed in a predecessor. If they have, the live-ins have changed, and the block needs reprocessing. Similarly, in transferTerminator, assign rather than |= the Out-Locations after processing a block, as we may have deleted some previously valid locations. This will mean that LiveDebugValues performs more propagation -- but that's necessary for it being correct. Differential Revision: https://reviews.llvm.org/D66599 llvm-svn: 369778
* [SLP] use range-for loops, fix formatting; NFCSanjay Patel2019-08-231-32/+32
| | | | | | | These are part of D57059, but that patch doesn't apply cleanly to trunk at this point, so we might as well remove some of the noise. llvm-svn: 369776
* [Reassoc] Small fix to support unary FNeg in NegateValue(...)Cameron McInally2019-08-231-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D66612 llvm-svn: 369772
* [Attributor][Fix] Deal with "growing" dereferenceabilityJohannes Doerfert2019-08-231-0/+6
| | | | | | | | | | | | | | | | | | Summary: If we have a negative inbounds offset dereferenceabily "grows". However, until we do not handle the overflow that can occur in the dereferenceable bytes and the problem with loops, we simply do not grow the state. Reviewers: sstefan1, uenoku Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66557 llvm-svn: 369771
* [Attributor][NFCI] Avoid lookups when resolving returned valuesJohannes Doerfert2019-08-231-3/+16
| | | | | | | | | | If the number of potentially returned values not change since the last traversal we do not need to visit the returned values again. This works as we only add values to the returned values set now. Differential Revision: https://reviews.llvm.org/D66484 llvm-svn: 369770
* [SLP] fix formatting; NFCSanjay Patel2019-08-231-4/+3
| | | | | | | These are part of D57059, but that patch doesn't apply cleanly to trunk at this point, so we might as well remove some of the noise. llvm-svn: 369769
* [Attributor] FIX: Treat new attributes as changed onesJohannes Doerfert2019-08-231-5/+5
| | | | | | | | | | | | | | | | | | | | | Summary: When we have new attributes and we end the fixpoint iteration because the iteration limit is reached, we need to treat the new ones as if they changed in the last iteration, as they might have. This adds a test for which we should not derive anything regardless of the iteration limit, e.g., if we abort there should not be any attributes manifested in the IR. Reviewers: uenoku, sstefan1 Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66549 llvm-svn: 369768
* [Attributor][NFCI] Try to avoid potential non-deterministic behaviorJohannes Doerfert2019-08-231-12/+10
| | | | | | | This commit replaces sets with set vectors in an effort to make the behavior of the Attributor deterministic. llvm-svn: 369767
* [ThinLTO] Fix handling of weak interposable symbolsTeresa Johnson2019-08-233-38/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Keep aliasees alive if their alias is live, otherwise we end up with an alias to a declaration, which is invalid. This can happen when the aliasee is weak and non-prevailing. This fix exposed the fact that we were then attempting to internalize the weak symbol, which was not exported as it was not prevailing. We should not internalize interposable symbols in general, unless this is the prevailing copy, since it can lead to incorrect inlining and other optimizations. Most of the changes in this patch are due to the restructuring required to pass down the prevailing callback. Finally, while implementing the test cases, I found that in the case of a weak aliasee that is still marked not live because its alias isn't live, after dropping the definition we incorrectly marked the declaration with weak linkage when resolving prevailing symbols in the module. This was due to some special case handling for symbols marked WeakLinkage in the summary located before instead of after a subsequent check for the symbol being a declaration. It turns out that we don't actually need this special case handling any more (looking back at the history, when that was added the code was structured quite differently) - we will correctly mark with weak linkage further below when the definition hasn't been dropped. Fixes PR42542. Reviewers: pcc Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66264 llvm-svn: 369766
* [MustExec] Add a generic "must-be-executed-context" explorerJohannes Doerfert2019-08-232-0/+119
| | | | | | | | | | | | | | | | Given an instruction I, the MustBeExecutedContextExplorer allows to easily traverse instructions that are guaranteed to be executed whenever I is. For now, these instruction have to be statically "after" I, in the same or different basic blocks. This patch also adds a pass which prints the must-be-executed-context for each instruction in a module. It is used to test the MustBeExecutedContextExplorer, for now on the examples given in the class comment of the MustBeExecutedIterator. Differential Revision: https://reviews.llvm.org/D65186 llvm-svn: 369765
* [mips] Reduce number of instructions used for loading a global symbol's valueSimon Atanasyan2019-08-231-5/+13
| | | | | | | | | | | | | | | | | | | | | | Now `lw/sw $reg, sym+offset` pseudo instructions for global symbol `sym` are lowering into the following three instructions. ``` lw $reg, %got(symbol)($gp) addiu $reg, $reg, offset lw/sw $reg, 0($reg) ``` It's possible to reduce the number of instructions by taking the offset in account in the final `lw/sw` command. This patch implements that optimization. ``` lw $reg, %got(symbol)($gp) lw/sw $reg, offset($reg) ``` Differential Revision: https://reviews.llvm.org/D66553 llvm-svn: 369756
* [mips] Do not include offset into `%got` expression for global symbolsSimon Atanasyan2019-08-231-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | Now pseudo instruction `la $6, symbol+8($6)` is expanding into the following chain of commands: ``` lw $1, %got(symbol+8)($gp) addiu $1, $1, 8 addu $6, $1, $6 ``` This is incorrect. When a linker handles the `R_MIPS_GOT16` relocation, it does not expect to get any addend and breaks on assertion. Otherwise it has to create new GOT entry for each unique "sym + offset" pair. Offset for a global symbol should be added to result of loading GOT entry by a separate `add` command. The patch fixes the problem by stripping off an offset from the expression passed to the `%got`. That's interesting that even current code inserts a separate `add` command. Differential Revision: https://reviews.llvm.org/D66552 llvm-svn: 369755
* Use VT::getHalfNumVectorElementsVT helpers in a few places. NFCI.Simon Pilgrim2019-08-232-10/+6
| | | | llvm-svn: 369751
* [X86][BtVer2] Add a read-advance to every implicit register use of ↵Andrea Di Biagio2019-08-231-4/+10
| | | | | | | | | | | | CMPXCHG8B/16B. This is a follow up of r369642. This patch assigns a ReadAfterLd to every implicit register use of instruction CMPXCHG8B and instruction CMPXCHG16B. Perf micro-benchmarks show that implicit registers are read after 3cy from the start of execution. llvm-svn: 369750
* [X86][BtVer2] Fix latency of ALU RMW instructions.Andrea Di Biagio2019-08-231-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Excluding ADC/SBB and the bit-test instructions (BTR/BTS/BTC), the observed latency of all other RMW integer arithmetic/logic instructions is 6cy and not 5cy. Example (ADD): ``` addb $0, (%rsp) # Latency: 6cy addb $7, (%rsp) # Latency: 6cy addb %sil, (%rsp) # Latency: 6cy addw $0, (%rsp) # Latency: 6cy addw $511, (%rsp) # Latency: 6cy addw %si, (%rsp) # Latency: 6cy addl $0, (%rsp) # Latency: 6cy addl $511, (%rsp) # Latency: 6cy addl %esi, (%rsp) # Latency: 6cy addq $0, (%rsp) # Latency: 6cy addq $511, (%rsp) # Latency: 6cy addq %rsi, (%rsp) # Latency: 6cy ``` The same latency profile applies to SUB/AND/OR/XOR/INC/DEC. The observed latency of ADC/SBB is 7-8cy. So we need a different write to model those. Latency of BTS/BTR/BTC is not fixed by this patch (they are much slower than what the model for btver2 currently reports). Differential Revision: https://reviews.llvm.org/D66636 llvm-svn: 369748
* [llvm-dlltool] Make sure to strip decorations from ExtName for renamed exportsMartin Storsjo2019-08-231-0/+1
| | | | | | | | | | | | ExtName should not be decorated, just like Name. This avoids double decoration on symbols in import libraries that use = for renaming functions. (Weak aliases, which use ==, worked fine with respect to decoration.) Differential Revision: https://reviews.llvm.org/D66617 llvm-svn: 369747
* [DAGCombine] GetNegatedExpression - add FMA\FMAD supportSimon Pilgrim2019-08-231-1/+52
| | | | | | | | If the accumulator and either of the multiply operands are negatable then we can we negate the entire expression. Differential Revision: https://reviews.llvm.org/D63141 llvm-svn: 369746
* [AMDGPU] gfx10 atomic optimizer changes.Jay Foad2019-08-233-57/+152
| | | | | | | | | | | | | | | | Summary: Add support for gfx10, where all DPP operations are confined to work within a single row of 16 lanes, and wave32. Reviewers: arsenm, sheredom, critson, rampitec Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, jfb, dstuttard, tpr, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65644 llvm-svn: 369745
* [yaml2obj] - Allow setting the symbol st_other field to any integer.George Rimar2019-08-231-3/+19
| | | | | | | | | | | | | | | | | st_other field of a symbol usually contains its visibility. Other bits are usually 0, though some targets, like MIPS can set them using the named bit field values. Problem is that there is no way to set an arbitrary value now, though that might be useful for our test cases. In this patch I introduced a way to set st_other to any numeric value using the new StOther field. I added a test and simplified the existent one to show the effect/benefit Differential revision: https://reviews.llvm.org/D66583 llvm-svn: 369742
* [X86] Make combineLoopSADPattern use CONCAT_VECTORS instead of ↵Craig Topper2019-08-231-3/+5
| | | | | | | | | INSERT_SUBVECTORS for widening with zeros. CONCAT_VECTORS is more canonical for the early DAG combine runs until we start getting into the op legalization phases. llvm-svn: 369734
* [X86] Improve lowering of v2i32 SAD handling in combineLoopSADPattern.Craig Topper2019-08-231-3/+10
| | | | | | | | | | | | | | | | | | | | | For v2i32 we only feed 2 i8 elements into the psadbw instructions with 0s in the other 14 bytes. The resulting psadbw instruction will produce zeros in bits [127:16] of the output. We need to take the result and feed it to a v2i32 add where the first element includes bits [15:0] of the sad result. The other element should be zero. Prior to this patch we were using a truncate to take 0 from bits 95:64 of the psadbw. This results in a pshufd to move those bits to 63:32. But since we also have zeroes in bits 63:32 of the psadbw output, we should just take those bits. The previous code probably worked better with promoting legalization, but now we use widening legalization. I've preserved the old behavior if -x86-experimental-vector-widening-legalization=false until we get that option removed. llvm-svn: 369733
* [IndVars] Fix a bug noticed by inspectionPhilip Reames2019-08-231-1/+2
| | | | | | We were computing the loop exit value, but not ensuring the addrec belonged to the loop whose exit value we were computing. I couldn't actually trip this; the test case shows the basic setup which *might* trip this, but none of the variations I've tried actually do. llvm-svn: 369730
* [AlignmentFromAssumptions] getNewAlignmentDiff(): use getURemExpr()Fangrui Song2019-08-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The alignment is calculated incorrectly, thus sometimes it doesn't generate aligned mov instructions, as shown by the example below: ``` // b.cc typedef long long index; extern "C" index g_tid; extern "C" index g_num; void add3(float* __restrict__ a, float* __restrict__ b, float* __restrict__ c) { index n = 64*1024; index m = 16*1024; index k = 4*1024; index tid = g_tid; index num = g_num; __builtin_assume_aligned(a, 32); __builtin_assume_aligned(b, 32); __builtin_assume_aligned(c, 32); for (index i0=tid*k; i0<m; i0+=num*k) for (index i1=0; i1<n*m; i1+=m) for (index i2=0; i2<k; i2++) c[i1+i0+i2] = b[i0+i2] + a[i1+i0+i2]; } ``` Compile with `clang b.cc -Ofast -march=skylake -mavx2 -S` ``` vmovaps -224(%rdi,%rbx,4), %ymm0 vmovups -192(%rdi,%rbx,4), %ymm1 # should be movaps vmovups -160(%rdi,%rbx,4), %ymm2 # should be movaps vmovups -128(%rdi,%rbx,4), %ymm3 # should be movaps vaddps -224(%rsi,%rbx,4), %ymm0, %ymm0 vaddps -192(%rsi,%rbx,4), %ymm1, %ymm1 vaddps -160(%rsi,%rbx,4), %ymm2, %ymm2 vaddps -128(%rsi,%rbx,4), %ymm3, %ymm3 vmovaps %ymm0, -224(%rdx,%rbx,4) vmovups %ymm1, -192(%rdx,%rbx,4) # should be movaps vmovups %ymm2, -160(%rdx,%rbx,4) # should be movaps vmovups %ymm3, -128(%rdx,%rbx,4) # should be movaps ``` Differential Revision: https://reviews.llvm.org/D66575 Patch by Dun Liang llvm-svn: 369723
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-231-8/+102
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
* [MC] Minor cleanup to MCFixup::Kind handling. NFC.Sam Clegg2019-08-2319-43/+39
| | | | | | | | | | Prefer `MCFixupKind` where possible and add getTargetKind() to convert to `unsigned` when needed rather than scattering cast operators around the place. Differential Revision: https://reviews.llvm.org/D59890 llvm-svn: 369720
* IR. Change strip* family of functions to not look through aliases.Peter Collingbourne2019-08-2212-39/+24
| | | | | | | | | | | | | | | | | | | | | | | | I noticed another instance of the issue where references to aliases were being replaced with aliasees, this time in InstCombine. In the instance that I saw it turned out to be only a QoI issue (a symbol ended up being missing from the symbol table due to the last reference to the alias being removed, preventing HWASAN from symbolizing a global reference), but it could easily have manifested as incorrect behaviour. Since this is the third such issue encountered (previously: D65118, D65314) it seems to be time to address this common error/QoI issue once and for all and make the strip* family of functions not look through aliases. Includes a test for the specific issue that I saw, but no doubt there are other similar bugs fixed here. As with D65118 this has been tested to make sure that the optimization isn't load bearing. I built Clang, Chromium for Linux, Android and Windows as well as the test-suite and there were no size regressions. Differential Revision: https://reviews.llvm.org/D66606 llvm-svn: 369697
* Fight a bit against global initializers. NFC.Benjamin Kramer2019-08-221-1/+1
| | | | llvm-svn: 369695
* GlobalISel: Don't create G_UADDE with constant false carry inMatt Arsenault2019-08-221-5/+7
| | | | | | | | The x86 tests are now broken (in paticular add-scalar.ll now hits the DAG fallback) due to not handling G_UADDO. The DAG x86 backend has a custom lowering for this, so that will need to be implemented. llvm-svn: 369673
* [MachO][TLOF] Use hasLocalLinkage to determine if indirect symbol is localFrancis Visoiu Mistrih2019-08-226-14/+14
| | | | | | | | | | | | | | | | | | | | | Local symbols in the indirect symbol table contain the value `INDIRECT_SYMBOL_LOCAL` and the corresponding __pointers entry must contain the address of the target. In r349060, I added support for local symbols in the indirect symbol table, which was checking if the symbol `isDefined` && `!isExternal` to determine if the symbol is local or not. It turns out that `isDefined` will return false if the user of the symbol comes before its definition, and we'll again generate .long 0 which will be the symbol at the adress 0x0. Instead of doing that, use GlobalValue::hasLocalLinkage() to check if the symbol is local. Differential Revision: https://reviews.llvm.org/D66563 llvm-svn: 369671
* [X86] Remove MCInstLower code that drops operands from some CALL and TAILJMP ↵Craig Topper2019-08-221-18/+8
| | | | | | | | | | instructions. Add asserts to verify operand count It appears the FIXME here was handled at some point. r159728 from 2012 seems to be at least aportion of fixing it. Differential Revision: https://reviews.llvm.org/D66570 llvm-svn: 369665
OpenPOWER on IntegriCloud