summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [TargetLowering] SimplifyMultipleUseDemandedBits - add VECTOR_SHUFFLE support.Simon Pilgrim2019-07-231-0/+23
| | | | | | | | If all the demanded elts are from one operand and are inline, then we can use the operand directly. The changes are mainly from SSE41 targets which has blendvpd but not cmpgtq, allowing the v2i64 comparison to be simplified as we only need the signbit from alternate v4i32 elements. llvm-svn: 366817
* [llvm-ar] Fix support for archives with members larger than 4GBOwen Reynolds2019-07-232-8/+17
| | | | | | | | | | | | | | | | llvm-ar outputs a strange error message when handling archives with members larger than 4GB due to not checking file size when passing the value as an unsigned 32 bit integer. This overflow issue caused malformed archives to be created.: https://bugs.llvm.org/show_bug.cgi?id=38058 This change allows for members above 4GB and will error in a case that is over the formats size limit, a 10 digit decimal integer. Differential Revision: https://reviews.llvm.org/D65093 llvm-svn: 366813
* [ARM][LowOverheadLoops] Fix branch target codegenSam Parker2019-07-234-37/+183
| | | | | | | | | | | | | | | | While lowering test.set.loop.iterations, it wasn't checked how the brcond was using the result and so the wls could branch to the loop preheader instead of not entering it. The same was true for loop.decrement.reg. So brcond and br_cc and now lowered manually when using the hwloop intrinsics. During this we now check whether the result has been negated and whether we're using SETEQ or SETNE and 0 or 1. We can then figure out which basic block the WLS and LE should be targeting. Differential Revision: https://reviews.llvm.org/D64616 llvm-svn: 366809
* Fix MSVC warning about extending a uint32_t shift result to uint64_t. NFCI.Simon Pilgrim2019-07-231-2/+2
| | | | llvm-svn: 366808
* [SLPVectorizer] Revert local change that got accidently got committed in ↵Simon Pilgrim2019-07-231-1/+0
| | | | | | | | rL366799 This wasn't part of D63281 llvm-svn: 366807
* [TargetLowering] Add SimplifyMultipleUseDemandedBitsSimon Pilgrim2019-07-232-1/+129
| | | | | | | | | | | | | | | | | | This patch introduces the DAG version of SimplifyMultipleUseDemandedBits, which attempts to peek through ops (mainly and/or/xor so far) that don't contribute to the demandedbits/elts of a node - which means we can do this even in cases where we have multiple uses of an op, which normally requires us to demanded all bits/elts. The intention is to remove a similar instruction - SelectionDAG::GetDemandedBits - once SimplifyMultipleUseDemandedBits has matured. The InstCombine version of SimplifyMultipleUseDemandedBits can constant fold which I haven't added here yet, and so far I've only wired this up to some basic binops (and/or/xor/add/sub/mul) to demonstrate its use. We do see a couple of regressions that need to be addressed: AMDGPU unsigned dot product codegen retains an AND mask (for ZERO_EXTEND) that it previously removed (but otherwise the dotproduct codegen is a lot better). X86/AVX2 has poor handling of vector ANY_EXTEND/ANY_EXTEND_VECTOR_INREG - it prematurely gets converted to ZERO_EXTEND_VECTOR_INREG. The code owners have confirmed its ok for these cases to fixed up in future patches. Differential Revision: https://reviews.llvm.org/D63281 llvm-svn: 366799
* [SLPVectorizer] Remove null-pointer test. NFCI.Simon Pilgrim2019-07-231-4/+4
| | | | | | cast<CallInst> shouldn't return null and we dereference the pointer in a lot of other places, causing both MSVC + cppcheck to warn about dereferenced null pointers llvm-svn: 366793
* [ARM] Rename NEONModImm to VMOVModImm. NFCDavid Green2019-07-238-46/+46
| | | | | | Rename NEONModImm to VMOVModImm as it is used in both NEON and MVE. llvm-svn: 366790
* [Attributor][NFC] Re-run clang-format on the Attributor.cppHideto Ueno2019-07-231-7/+4
| | | | llvm-svn: 366789
* [Attributor] Deduce "dereferenceable" attributeHideto Ueno2019-07-231-14/+429
| | | | | | | | | | | | | | | | | | | | | Summary: Deduce dereferenceable attribute in Attributor. These will be added in a later patch. * dereferenceable(_or_null)_globally (D61652) * Deduction based on load instruction (similar to D64258) Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64876 llvm-svn: 366788
* [DAGCombiner] Make ShrinkLoadReplaceStoreWithStore return an SDValue instead ↵Craig Topper2019-07-231-9/+8
| | | | | | | | | | of an SDNode*. NFCI The function was calling getNode() on an SDValue to return and the caller turned the result back into a SDValue. So just return the original SDValue to avoid this. llvm-svn: 366779
* [DAGCombiner] Use SDNode::isOperandOf to simplify some code. NFCICraig Topper2019-07-231-7/+1
| | | | llvm-svn: 366778
* [LLVM-C] Improve Bindings to The Internalize PassRobert Widmann2019-07-231-0/+9
| | | | | | | | | | | | | | | | Summary: Adds a binding to the internalize pass that allows the caller to pass a function pointer that acts as the visibility-preservation predicate. Previously, one could only pass an unsigned value (not LLVMBool?) that directed the pass to consider "main" or not. Reviewers: whitequark, deadalnix, harlanhaskins Reviewed By: whitequark, harlanhaskins Subscribers: kren1, hiraditya, llvm-commits, harlanhaskins Tags: #llvm Differential Revision: https://reviews.llvm.org/D62456 llvm-svn: 366777
* [PowerPC] Replace float load/store pair with integer load/store pair when ↵Zi Xuan Wu2019-07-231-0/+12
| | | | | | | | | | | | | | it's only used in load/store Replace float load/store pair with integer load/store pair when it's only used in load/store, because float load/store instructions cost more cycles then integer load/store. A typical scenario is when there is a call with more than 13 float arguments passing, we need pass them by stack. So we need a load/store pair to do such memory operation if the variable is global variable. Differential Revision: https://reviews.llvm.org/D64195 llvm-svn: 366775
* Inline function call into assert to fix unused variable warning.Richard Trieu2019-07-231-3/+2
| | | | llvm-svn: 366774
* Move variable out from debug only section.Richard Trieu2019-07-231-2/+0
| | | | | | | MFI is no longer just needed for an assert. Move it out of the debug only section to allow non-assert builds to be able to find it. llvm-svn: 366773
* Fixing build error from commit 95cbc3dStefan Stipanovic2019-07-222-1/+175
| | | | | | | | | | | | | | | [Attributor] Liveness analysis. Liveness analysis abstract attribute used to indicate which BasicBlocks are dead and can therefore be ignored. Right now we are only looking at noreturn calls. Reviewers: jdoerfert, uenoku Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D64162 llvm-svn: 366769
* [Statepoints] Fix a bug in statepoint lowering for functions w/no-realign-stackPhilip Reames2019-07-221-1/+8
| | | | | | | | | | We were silently using the ABI alignment for all of the stores generated for deopt and gc values. We'd gotten the alignment of the stack slot itself properly reduced (via MachineFrameInfo's clamping), but having the MMO on the store incorrect was enough for us to generate an aligned store to a unaligned location. The simplest fix would have been to just pass the alignment to the helper function, but once we do that, the helper function doesn't really help. So, inline it and directly call the MMO version of DAG.getStore with a properly constructed MMO. Note that there's a separate performance possibility here. Even if we *can* realign stacks, we probably don't *want to* if all of the stores are in slowpaths. But that's a later patch, if at all. :) llvm-svn: 366765
* [DWARF] Add more error handling to debug line parser.Jonas Devlieghere2019-07-221-34/+68
| | | | | | | | | | This patch exnteds the error handling in the debug line parser to get rid of the existing MD5 assertion. I want to reuse the debug line parser from LLVM in LLDB where we cannot crash on invalid input. Differential revision: https://reviews.llvm.org/D64544 llvm-svn: 366762
* Revert "Fixing build error from commit 9285295."Stefan Stipanovic2019-07-222-173/+1
| | | | | | This reverts commit 95cbc3da8871f43c1ce2b2926afaedcd826202b1. llvm-svn: 366759
* Analysis: Don't look through aliases when simplifying GEPs.Peter Collingbourne2019-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | It is not safe in general to replace an alias in a GEP with its aliasee if the alias can be replaced with another definition (i.e. via strong/weak resolution (linkonce_odr) or via symbol interposition (default visibility in ELF)) while the aliasee cannot. An example of how this can go wrong is in the included test case. I was concerned that this might be a load-bearing misoptimization (it's possible for us to use aliases to share vtables between base and derived classes, and on Windows, vtable symbols will always be aliases in RTTI mode, so this change could theoretically inhibit trivial devirtualization in some cases), so I built Chromium for Linux and Windows with and without this change. The file sizes of the resulting binaries were identical, so it doesn't look like this is going to be a problem. Differential Revision: https://reviews.llvm.org/D65118 llvm-svn: 366754
* Fixing build error from commit 9285295.Stefan Stipanovic2019-07-222-1/+173
| | | | | | | | | | | | | | | [Attributor] Liveness analysis. Liveness analysis abstract attribute used to indicate which BasicBlocks are dead and can therefore be ignored. Right now we are only looking at noreturn calls. Reviewers: jdoerfert, uenoku Subscribers: hiraditya, llvm-commits Differential revision: https://reviews.llvm.org/D64162 llvm-svn: 366753
* [NFC][PatternMatch] Refactor code into a proper "matcher for any integral ↵Roman Lebedev2019-07-221-18/+1
| | | | | | | | | constant" Having it as a proper matcher is better for reusability elsewhere (in a follow-up patch.) llvm-svn: 366752
* AMDGPU: Don't use SDNodeXForm for DS offset outputMatt Arsenault2019-07-221-12/+12
| | | | | | | | | | | The xform has no real valuewhen it's using out of a complex pattern output. The complex pattern was already creating TargetConstants with i16, so this was just unnecessary machinery. This allows global isel to import the simple cases once the complex pattern is implemented. llvm-svn: 366743
* Temporarily Revert "[Attributor] Liveness analysis." as it's breaking the build.Eric Christopher2019-07-222-175/+1
| | | | | | This reverts commit 9285295f75a231dc446fa7cbc10a0a391b3434a5. llvm-svn: 366737
* [Attributor] Liveness analysis.Stefan Stipanovic2019-07-222-1/+175
| | | | | | | | | | | | | Liveness analysis abstract attribute used to indicate which BasicBlocks are dead and can therefore be ignored. Right now we are only looking at noreturn calls. Reviewers: jdoerfert, uenoku Subscribers: hiraditya, llvm-commits Differential revision: https://reviews.llvm.org/D64162 llvm-svn: 366736
* [X86] When using AND+PACKUS in lowerV16I8Shuffle, generate the build vector ↵Craig Topper2019-07-221-5/+4
| | | | | | | | | | | | | | | | directly in v16i8 with the correct 0x00 or 0xFF elements rather than using another VT and bitcasting it. The build_vector will become a constant pool load. By using the desired type initially, it ensures we don't generate a bitcast of the constant pool load which will need to be folded with the load. While experimenting with another patch, I noticed that when the load type and the constant pool type don't match, then SimplifyDemandedBits can't handle it. While we should probably fix that, this was a simple way to fix the issue I saw. llvm-svn: 366732
* [NFC][PowerPC]Change ADDIStocHA to ADDIStocHA8 to follow 64-bit naming ↵Jason Liu2019-07-227-19/+19
| | | | | | | | | | | | | | | convention Summary: Since we are planning to add ADDIStocHA for 32bit in later patch, we decided to change 64bit one first to follow naming convention with 8 behind opcode. Patch by: Xiangling_L Differential Revision: https://reviews.llvm.org/D64814 llvm-svn: 366731
* [Attributor] NoAlias on return values.Stefan Stipanovic2019-07-221-4/+109
| | | | | | | | | | | | | Porting function return value attribute noalias to attributor. This will be followed with a patch for callsite and function argumets. Reviewers: jdoerfert Subscribers: lebedev.ri, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D63067 llvm-svn: 366728
* Stubs out TLOF for AIX and add support for common vars in assembly output.Sean Fertile2019-07-227-6/+112
| | | | | | | | | Stubs out a TargetLoweringObjectFileXCOFF class, implementing only SelectSectionForGlobal for common symbols. Also adds an override of EmitGlobalVariable in PPCAIXAsmPrinter which adds a number of defensive errors and adds support for emitting common globals. llvm-svn: 366727
* [SafeStack] Insert the deref after the offsetPetr Hosek2019-07-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging code that uses SafeStack, we've noticed that LLVM produces an invalid DWARF. Concretely, in the following example: int main(int argc, char* argv[]) { std::string value = ""; printf("%s\n", value.c_str()); return 0; } DWARF would describe the value variable as being located at: DW_OP_breg14 R14+0, DW_OP_deref, DW_OP_constu 0x20, DW_OP_minus The assembly to get this variable is: leaq -32(%r14), %rbx The order of operations in the DWARF symbols is incorrect in this case. Specifically, the deref is incorrect; this appears to be incorrectly re-inserted in repalceOneDbgValueForAlloca. With this change which inserts the deref after the offset instead of before it, LLVM produces correct DWARF: DW_OP_breg14 R14-32 Differential Revision: https://reviews.llvm.org/D64971 llvm-svn: 366726
* WholeProgramDevirt: Teach the pass to respect the global's alignment.Peter Collingbourne2019-07-221-4/+7
| | | | | | | | | | | | | | | | | | | The bytes inserted before an overaligned global need to be padded according to the alignment set on the original global in order for the initializer to meet the global's alignment requirements. The previous implementation that padded to the pointer width happened to be correct for vtables on most platforms but may do the wrong thing if the vtable has a larger alignment. This issue is visible with a prototype implementation of HWASAN for globals, which will overalign all globals including vtables to 16 bytes. There is also no padding requirement for the bytes inserted after the global because they are never read from nor are they significant for alignment purposes, so stop inserting padding there. Differential Revision: https://reviews.llvm.org/D65031 llvm-svn: 366725
* [PowerPC] Fix comment on MO_PLT Target Operand Flag. [NFC]Sean Fertile2019-07-221-2/+2
| | | | | | Patch by Xiangling Liao. llvm-svn: 366724
* [Object][XCOFF] Remove extra includes from XCOFF related files. [NFC]Sean Fertile2019-07-221-5/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D60885 llvm-svn: 366723
* LowerTypeTests: Teach the pass to respect global alignments.Peter Collingbourne2019-07-221-19/+26
| | | | | | | | | | | | | | | We were previously ignoring alignment entirely when combining globals together in this pass. There are two main things that we need to do here: add additional padding before each global to meet the alignment requirements, and set the combined global's alignment to the maximum of all of the original globals' alignments. Since we now need to calculate layout as we go anyway, use the calculated layout to produce GlobalLayout instead of using StructLayout. Differential Revision: https://reviews.llvm.org/D65033 llvm-svn: 366722
* Changes to emit CodeView debug info nested type records properly using ↵Nilanjana Basu2019-07-222-2/+23
| | | | | | MCStreamer directives llvm-svn: 366720
* [SLPVectorizer] Fix some MSVC/cppcheck uninitialized variable warnings. NFCI.Simon Pilgrim2019-07-221-3/+3
| | | | llvm-svn: 366712
* Revert "Reland [ELF] Loose a condition for relocation with a symbol"Vlad Tsyrklevich2019-07-221-0/+5
| | | | | | | This reverts commit r366686 as it appears to be causing buildbot failures on sanitizer-x86_64-linux-android and sanitizer-x86_64-linux. llvm-svn: 366708
* TableGen: Support physical register inputs > 255Matt Arsenault2019-07-221-1/+4
| | | | | | | This was truncating register value that didn't fit in unsigned char. Switch AMDGPU sendmsg intrinsics to using a tablegen pattern. llvm-svn: 366695
* [ARM][LowOverheadLoops] Revert remaining pseudosSam Parker2019-07-221-12/+56
| | | | | | | | | | | ARMLowOverheadLoops would assert a failure if it did not find all the pseudo instructions that comprise the hardware loop. Instead of doing this, iterate through all the instructions of the function and revert any remaining pseudo instructions that haven't been converted. Differential Revision: https://reviews.llvm.org/D65080 llvm-svn: 366691
* Reland [ELF] Loose a condition for relocation with a symbolNikola Prica2019-07-221-5/+0
| | | | | | | | | | | | | | | | | | | This patch was not the reason of the buildbot failure. Deleted code was introduced as a work around for a bug in the gold linker (http://sourceware.org/PR16794). Test case that was given as a reason for this part of code, the one on previous link, now works for the gold. This condition is too strict and when a code is compiled with debug info it forces generation of numerous relocations with symbol for architectures that do not have relocation addend. Reviewers: arsenm, espindola Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D64327 llvm-svn: 366686
* AMDGPU/GlobalISel: Remove unnecessary codeMatt Arsenault2019-07-221-4/+0
| | | | | | | The minnum/maxnum case are dead, and the cvt is handled by the default. llvm-svn: 366685
* [ARM] Fix for MVE VPT block passDavid Green2019-07-221-3/+18
| | | | | | | | | We need to ensure that the number of T's is correct when adding multiple instructions into the same VPT block. Differential revision: https://reviews.llvm.org/D65049 llvm-svn: 366684
* [X86] EltsFromConsecutiveLoads - support common source loads (REAPPLIED)Simon Pilgrim2019-07-221-5/+62
| | | | | | | | | | | | | | This patch enables us to find the source loads for each element, splitting them into a Load and ByteOffset, and attempts to recognise consecutive loads that are in fact from the same source load. A helper function, findEltLoadSrc, recurses to find a LoadSDNode and determines the element's byte offset within it. When attempting to match consecutive loads, byte offsetted loads then attempt to matched against a previous load that has already been confirmed to be a consecutive match. Next step towards PR16739 - after this we just need to account for shuffling/repeated elements to create a vector load + shuffle. Fixed out of bounds load assert identified in rL366501 Differential Revision: https://reviews.llvm.org/D64551 llvm-svn: 366681
* Added address-space mangling for stack related intrinsicsChristudasan Devadasan2019-07-225-10/+21
| | | | | | | | | | | | Modified the following 3 intrinsics: int_addressofreturnaddress, int_frameaddress & int_sponentry. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D64561 llvm-svn: 366679
* [IPRA][ARM] Make use of the "returned" parameter attributeOliver Stannard2019-07-224-0/+21
| | | | | | | | | | | | ARM has code to recognise uses of the "returned" function parameter attribute which guarantee that the value passed to the function in r0 will be returned in r0 unmodified. IPRA replaces the regmask on call instructions, so needs to be told about this to avoid reverting the optimisation. Differential revision: https://reviews.llvm.org/D64986 llvm-svn: 366669
* [AMDGPU] Save some work when an atomic op has no usesJay Foad2019-07-221-67/+70
| | | | | | | | | | | | | | | | | | Summary: In the atomic optimizer, save doing a bunch of work and generating a bunch of dead IR in the fairly common case where the result of an atomic op (i.e. the value that was in memory before the atomic op was performed) is not used. NFC. Reviewers: arsenm, dstuttard, tpr Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64981 llvm-svn: 366667
* [Loop Peeling] Fix the handling of branch weights of peeled off branches.Serguei Katkov2019-07-221-62/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current algorithm to update branch weights of latch block and its copies is based on the assumption that number of peeling iterations is approximately equal to trip count. However it is not correct. According to profitability check in one case we can decide to peel in case it helps to reduce the number of phi nodes. In this case the number of peeled iteration can be less then estimated trip count. This patch introduces another way to set the branch weights to peeled of branches. Let F is a weight of the edge from latch to header. Let E is a weight of the edge from latch to exit. F/(F+E) is a probability to go to loop and E/(F+E) is a probability to go to exit. Then, Estimated TripCount = F / E. For I-th (counting from 0) peeled off iteration we set the the weights for the peeled latch as (TC - I, 1). It gives us reasonable distribution, The probability to go to exit 1/(TC-I) increases. At the same time the estimated trip count of remaining loop reduces by I. As a result after peeling off N iteration the weights will be (F - N * E, E) and trip count of loop becomes F / E - N or TC - N. The idea is taken from the review of the patch D63918 proposed by Philip. Reviewers: reames, mkuper, iajbar, fhahn Reviewed By: reames Subscribers: hiraditya, zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D64235 llvm-svn: 366665
* [X86] SimplifyDemandedVectorEltsForTargetNode - Move SUBV_BROADCAST ↵Simon Pilgrim2019-07-211-19/+13
| | | | | | | | narrowing handling. NFCI. Move the narrowing of SUBV_BROADCAST to where we handle all the other opcodes. llvm-svn: 366660
* [InstCombine] Update comment I missed in r366649. NFCCraig Topper2019-07-211-1/+1
| | | | llvm-svn: 366658
OpenPOWER on IntegriCloud