summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [libFuzzer] don't timeout when loading the corpus. Be a bit more verbose ↵Kostya Serebryany2016-02-172-1/+7
| | | | | | when loading large corpus. llvm-svn: 261143
* Create masked gather and scatter intrinsics in Loop Vectorizer.Elena Demikhovsky2016-02-172-111/+254
| | | | | | | | | Loop vectorizer now knows to vectorize GEP and create masked gather and scatter intrinsics for random memory access. The feature is enabled on AVX-512 target. Differential Revision: http://reviews.llvm.org/D15690 llvm-svn: 261140
* Fix load alignement when unpacking aggregates structsAmaury Sechet2016-02-171-12/+26
| | | | | | | | | | | | Summary: Store and loads unpacked by instcombine do not always have the right alignement. This explicitely compute the alignement and set it. Reviewers: dblaikie, majnemer, reames, hfinkel, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17326 llvm-svn: 261139
* Revert "Reapply commit r258404 with fix."David Majnemer2016-02-171-231/+11
| | | | | | This reverts commit r259357, it caused PR26629. llvm-svn: 261137
* [ObjCARC] Handle ARCInstKind::ClaimRV in OptimizeIndividualCalls.Frederic Riss2016-02-171-0/+1
| | | | | | | | | When support for objc_unsafeClaimAutoreleasedReturnValue has been added to the ARC optimizer in r258970, one case was missed which would lead the optimizer to execute an llvm_unreachable. In this case, just handle ClaimRV in the same way we handle RetainRV. llvm-svn: 261134
* [Hexagon] Replacing reference/dereference with reference cast.Colin LeMahieu2016-02-171-4/+4
| | | | llvm-svn: 261133
* Remove superfluous semicolon.Nico Weber2016-02-171-1/+1
| | | | llvm-svn: 261128
* Revert r261070, it caused PR26652 / PR26653.Nico Weber2016-02-171-126/+0
| | | | llvm-svn: 261127
* [WinEH] Optimize WinEH state storesDavid Majnemer2016-02-171-32/+175
| | | | | | | | | | | | | | | | | | | | | | | | | 32-bit x86 Windows targets use a linked-list of nodes allocated on the stack, referenced to via thread-local storage. The personality routine interprets one of the fields in the node as a 'state number' which indicates where the personality routine should transfer control. State transitions are possible only before call-sites which may throw exceptions. Our previous scheme had us update the state number before all call-sites which may throw. Instead, we can try to minimize the number of times we need to store by reasoning about the nearest store which dominates the current call-site. If the last store agrees with the current call-site, then we know that the state-update is redundant and can be elided. This is largely straightforward: an RPO walk of the blocks allows us to correctly forward propagate the information when the function is a DAG. Currently, loops are not handled optimally and may trigger superfluous state stores. Differential Revision: http://reviews.llvm.org/D16763 llvm-svn: 261122
* Add a profile summary class specific to instrumentation profiles.Easwaran Raman2016-02-173-23/+34
| | | | | | | | | Modify ProfileSummary class to make it not instrumented profile specific. Add a new InstrumentedProfileSummary class that inherits from ProfileSummary. Differential Revision: http://reviews.llvm.org/D17310 llvm-svn: 261119
* [Hexagon] Loop instructions don't need special processing. Extension and ↵Colin LeMahieu2016-02-171-25/+0
| | | | | | fitting is performed by generic code and the comment is incorrect, loops don't have a separate extended opcode. llvm-svn: 261118
* [NVPTX] Annotate convergent intrinsics as convergent.Justin Lebar2016-02-171-0/+2
| | | | | | | | | | | | | | | Summary: Previously the machine instructions for bar.sync &co. were not marked as convergent. This resulted in some MI passes (such as TailDuplication, fixed in an upcoming patch) doing unsafe things to these instructions. Reviewers: jingyue Subscribers: llvm-commits, tra, jholewinski, hfinkel Differential Revision: http://reviews.llvm.org/D17318 llvm-svn: 261115
* [NVPTX] Annotate call machine instructions as calls.Justin Lebar2016-02-171-0/+2
| | | | | | | | | | | | | | | | | Summary: Otherwise we'll try to do unsafe optimizations on these MIs, such as sinking loads below calls. (I suspect that this is not the only bug in the NVPTX instruction tablegen files; I need to comb through them.) Reviewers: jholewinski, tra Subscribers: jingyue, jhen, llvm-commits Differential Revision: http://reviews.llvm.org/D17315 llvm-svn: 261113
* Represent the dynamic table itself with a DynRegionInfo.Rafael Espindola2016-02-171-2/+0
| | | | | | | | | | | | The dynamic table is also an array of a fixed structure, so it can be represented with a DynReginoInfo. No major functionality change. The extra error checking is covered by existing tests with a broken dynamic program header. Idea extracted from r260488. I did the extra cleanups. llvm-svn: 261107
* [Hexagon] Fold object construction into map::insertKrzysztof Parzyszek2016-02-171-2/+2
| | | | llvm-svn: 261096
* AVX512: Fix LowerMSCATTER() return value.Igor Breger2016-02-171-1/+1
| | | | | | | | | | | Bug description: The bug was discovered when test was compiled with -O0. In case scatter result is DAG root , VectorLegalizer failed (assert) due to LowerMSCATTER() return kmask as result. Change LowerMSCATTER() to return chain as original node do. Differential Revision: http://reviews.llvm.org/D17331 llvm-svn: 261090
* [mips] Removed the SHF_ALLOC flag and the SHT_REL flag from the .pdr section.Scott Egerton2016-02-171-2/+1
| | | | | | | | | | | | This section is used for debug information and has no need to be in memory at runtime. This patch also fixes an error when compiling the Linux kernel. The error is that there are relocations within the .pdr section in a VDSO. SHT_REL was removed as it is a section type and not a section flag, therefore it does not make sense for it to be there. With this patch, LLVM now emits the same flags as the GNU assembler. llvm-svn: 261083
* [X86][AVX] Support bit-blend integer shuffles for 256-bit integer vectorsSimon Pilgrim2016-02-171-1/+3
| | | | | | | | | | | | AVX1 doesn't support the shuffling of 256-bit integer vectors. For 32/64-bit elements we get around this by shuffling as float/double but for 8/16-bit elements (assuming they can't widen) we currently just split, shuffle as 128-bit vectors and concatenate the results back. This patch adds the ability to lower using the bit-blend patterns before defaulting to the splitting behaviour. Part 2 of 2 Differential Revision: http://reviews.llvm.org/D17292 llvm-svn: 261082
* [X86][AVX] Support bit-mask integer shuffles for 256-bit integer vectorsSimon Pilgrim2016-02-171-2/+6
| | | | | | | | | | | | AVX1 doesn't support the shuffling of 256-bit integer vectors. For 32/64-bit elements we get around this by shuffling as float/double but for 8/16-bit elements (assuming they can't widen) we currently just split, shuffle as 128-bit vectors and concatenate the results back. This patch adds the ability to lower using the bit-mask patterns before defaulting to the splitting behaviour. In some cases this ends up matching what AVX2 would do anyhow or what AVX1 does on the split vectors. Part 1 of 2 Differential Revision: http://reviews.llvm.org/D17292 llvm-svn: 261081
* [X86][SSE] Tidyup BUILD_VECTOR operand collection. NFCI.Simon Pilgrim2016-02-171-23/+20
| | | | | | | | Avoid reuse of operand variables, keep them local to a particular lowering - the operand collection is unique to each case anyhow. Renamed from V to Ops to more closely match their purpose. llvm-svn: 261078
* [Hexagon] cast<> a reference instead of referencing + dereferencing.Benjamin Kramer2016-02-171-1/+1
| | | | llvm-svn: 261077
* Detecte vector reduction operations just before instruction selection.Cong Hou2016-02-171-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | This patch detects vector reductions before instruction selection. Vector reductions are vectorized reduction operations, and for such operations we have freedom to reorganize the elements of the result as long as the reduction of them stay unchanged. This will enable some reduction pattern recognition during instruction combine such as SAD/dot-product on X86. A flag is added to SDNodeFlags to mark those vector reduction nodes to be checked during instruction combine. To detect those vector reductions, we search def-use chains starting from the given instruction, and check if all uses fall into two categories: 1. Reduction with another vector. 2. Reduction on all elements. in which 2 is detected by recognizing the pattern that the loop vectorizer generates to reduce all elements in the vector outside of the loop, which includes several ShuffleVector and one ExtractElement instructions. Differential revision: http://reviews.llvm.org/D15250 llvm-svn: 261070
* Revert r260979 "[X86] Enable the LEA optimization pass by default."Hans Wennborg2016-02-171-5/+4
| | | | | | Asserts are still firing in Chromium builds. PR26575. llvm-svn: 261058
* Revert "Query the StringMap only once when creating MDString (NFC)"Mehdi Amini2016-02-171-6/+11
| | | | | | | | | This reverts commit r261030 and r261036. (The revision was marked "approved" on phabricator, but some concerns were raised on the mailing list. Thanks D. Blaikie for notifying me.) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261055
* [AliasSetTracker] Teach AliasSetTracker about MemSetInstHaicheng Wu2016-02-171-0/+41
| | | | | | | This change is to fix the problem discussed in http://lists.llvm.org/pipermail/llvm-dev/2016-February/095446.html. llvm-svn: 261052
* WebAssembly: update expected failuresJF Bastien2016-02-171-3/+0
| | | | | | r261050 seems to inadvertently fix the assertion failure. llvm-svn: 261051
* [WebAssembly] Call memcpy for large byval copies.Dan Gohman2016-02-171-1/+1
| | | | | | | | | | This fixes very slow compilation on test/CodeGen/Generic/2010-11-04-BigByval.ll . Note that MaxStoresPerMemcpy and friends are not yet carefully tuned so the cutoff point is currently somewhat arbitrary. However, it's important that there be a cutoff point so that we don't emit unbounded quantities of loads and stores. llvm-svn: 261050
* WebAssembly: update expected test failuresJF Bastien2016-02-171-3/+0
| | | | | | r261032 adds frame address support. llvm-svn: 261044
* [LCG] Construct an actual call graph with call-edge SCCs nested insideChandler Carruth2016-02-171-388/+1181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reference-edge SCCs. This essentially builds a more normal call graph as a subgraph of the "reference graph" that was the old model. This allows both to exist and the different use cases to use the aspect which addresses their needs. Specifically, the pass manager and other *ordering* constrained logic can use the reference graph to achieve conservative order of visit, while analyses reasoning about attributes and other properties derived from reachability can reason about the direct call graph. Note that this isn't necessarily complete: it doesn't model edges to declarations or indirect calls. Those can be found by scanning the instructions of the function if desirable, and in fact every user currently does this in order to handle things like calls to instrinsics. If useful, we could consider caching this information in the call graph to save the instruction scans, but currently that doesn't seem to be important. An important realization for why the representation chosen here works is that the call graph is a formal subset of the reference graph and thus both can live within the same data structure. All SCCs of the call graph are necessarily contained within an SCC of the reference graph, etc. The design is to build 'RefSCC's to model SCCs of the reference graph, and then within them more literal SCCs for the call graph. The formation of actual call edge SCCs is not done lazily, unlike reference edge 'RefSCC's. Instead, once a reference SCC is formed, it directly builds the call SCCs within it and stores them in a post-order sequence. This is used to provide a consistent platform for mutation and update of the graph. The post-order also allows for very efficient updates in common cases by bounding the number of nodes (and thus edges) considered. There is considerable common code that I'm still looking for the best way to factor out between the various DFS implementations here. So far, my attempts have made the code harder to read and understand despite reducing the duplication, which seems a poor tradeoff. I've not given up on figuring out the right way to do this, but I wanted to wait until I at least had the system working and tested to continue attempting to factor it differently. This also requires introducing several new algorithms in order to handle all of the incremental update scenarios for the more complex structure involving two edge colorings. I've tried to comment the algorithms sufficiently to make it clear how this is expected to work, but they may still need more extensive documentation. I know that there are some changes which are not strictly necessarily coupled here. The process of developing this started out with a very focused set of changes for the new structure of the graph and algorithms, but subsequent changes to bring the APIs and code into consistent and understandable patterns also ended up touching on other aspects. There was no good way to separate these out without causing *massive* merge conflicts. Ultimately, to a large degree this is a rewrite of most of the core algorithms in the LCG class and so I don't think it really matters much. Many thanks to the careful review by Sanjoy Das! Differential Revision: http://reviews.llvm.org/D16802 llvm-svn: 261040
* [X86] Fix a shrink-wrapping miscompile around __chkstkReid Kleckner2016-02-171-7/+6
| | | | | | | | | __chkstk clobbers EAX. If EAX is live across the prologue, then we have to take extra steps to save it. We already had code to do this if EAX was a register parameter. This change adapts it to work when shrink wrapping is used. llvm-svn: 261039
* [WebAssembly] Use SDValue::getConstantOperandVal. NFC.Dan Gohman2016-02-171-1/+1
| | | | llvm-svn: 261037
* Fix build LLVM with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON on WindowsAndrew Kaylor2016-02-162-2/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D16940 llvm-svn: 261033
* [WebAssembly] Implement __builtin_frame_address.Dan Gohman2016-02-164-8/+23
| | | | | | Differential Revision: http://reviews.llvm.org/D17307 llvm-svn: 261032
* Query the StringMap only once when creating MDString (NFC)Mehdi Amini2016-02-161-11/+6
| | | | | | | | | | | | | Summary: Loading IR with debug info improves MDString::get() from 19ms to 10ms. Reviewers: dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16597 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261030
* Define the ThinLTO Pipeline (experimental)Mehdi Amini2016-02-161-2/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the contrary to Full LTO, ThinLTO can afford to shift compile time from the frontend to the linker: both phases are parallel (even if it is not totally "free": projects like clang are reusing product from the "compile phase" for multiple link, think about libLLVMSupport reused for opt, llc, etc.). This pipeline is based on the proposal in D13443 for full LTO. We didn't move forward on this proposal because the LTO link was far too long after that. We believe that we can afford it with ThinLTO. The ThinLTO pipeline integrates in the regular O2/O3 flow: - The compile phase perform the inliner with a somehow lighter function simplification. (TODO: tune the inliner thresholds here) This is intendend to simplify the IR and get rid of obvious things like linkonce_odr that will be inlined. - The link phase will run the pipeline from the start, extended with some specific passes that leverage the augmented knowledge we have during LTO. Especially after the inliner is done, a sequence of globalDCE/globalOpt is performed, followed by another run of the "function simplification" passes. It is not clear if this part of the pipeline will stay as is, as the split model of ThinLTO does not allow the same benefit as FullLTO without added tricks. The measurements on the public test suite as well as on our internal suite show an overall net improvement. The binary size for the clang executable is reduced by 5%. We're still tuning it with the bringup of ThinLTO and it will evolve, but this should provide a good starting point. Reviewers: tejohnson Differential Revision: http://reviews.llvm.org/D17115 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261029
* Refactor the PassManagerBuilder: extract a ↵Mehdi Amini2016-02-161-72/+76
| | | | | | | | | | "addFunctionSimplificationPasses()" (NFC) It is intended to contains the passes run over a function after the inliner is done with a function and before it moves to its callers. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261028
* [X86] Remove the now-unused X86ISD::PSIGN. NFC.Ahmed Bougacha2016-02-166-46/+30
| | | | llvm-svn: 261025
* [X86] Generalize logic blend of (x, -x) combine to match (-x, x).Ahmed Bougacha2016-02-161-7/+17
| | | | | | I suspect this is what let PR26110 lie dormant for so long. llvm-svn: 261024
* [X86] Don't turn (c?-v:v) into (c?-v:0) by blindly using PSIGN.Ahmed Bougacha2016-02-161-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we sometimes miscompile this vector pattern: (c ? -v : v) We lower it to (because "c" is <4 x i1>, lowered as a vector mask): (~c & v) | (c & -v) When we have SSSE3, we incorrectly lower that to PSIGN, which does: (c < 0 ? -v : c > 0 ? v : 0) in other words, when c is either all-ones or all-zero: (c ? -v : 0) While this is an old bug, it rarely triggers because the PSIGN combine is too sensitive to operand order. This will be improved separately. Note that the PSIGN tests are also incorrect. Consider: %b.lobit = ashr <4 x i32> %b, <i32 31, i32 31, i32 31, i32 31> %sub = sub nsw <4 x i32> zeroinitializer, %a %0 = xor <4 x i32> %b.lobit, <i32 -1, i32 -1, i32 -1, i32 -1> %1 = and <4 x i32> %a, %0 %2 = and <4 x i32> %b.lobit, %sub %cond = or <4 x i32> %1, %2 ret <4 x i32> %cond if %b is zero: %b.lobit = <4 x i32> zeroinitializer %sub = sub nsw <4 x i32> zeroinitializer, %a %0 = <4 x i32> <i32 -1, i32 -1, i32 -1, i32 -1> %1 = <4 x i32> %a %2 = <4 x i32> zeroinitializer %cond = or <4 x i32> %a, zeroinitializer ret <4 x i32> %a whereas we currently generate: psignd %xmm1, %xmm0 retq which returns 0, as %xmm1 is 0. Instead, use a pure logic sequence, as described in: https://graphics.stanford.edu/~seander/bithacks.html#ConditionalNegate Fixes PR26110. Differential Revision: http://reviews.llvm.org/D17181 llvm-svn: 261023
* [X86] Extract PSIGN/BLENDVP combine. NFC.Ahmed Bougacha2016-02-161-77/+95
| | | | llvm-svn: 261021
* [X86] Extract ANDNP combine. NFC.Ahmed Bougacha2016-02-161-61/+57
| | | | | | This makes it IMO more readable and reduces indentation. llvm-svn: 261020
* Bitcode writer: fix a typo, using getName() instead of getSourceFileName()Mehdi Amini2016-02-161-2/+2
| | | | | | | | When emitting the source filename, the encoding of the string was checked against the name instead of the filename. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 261019
* [WebAssembly] Update torture test expectationsDerek Schuff2016-02-161-7/+0
| | | | | | These were fixed with r260978 llvm-svn: 261017
* [codeview] Bail on a DBG_VALUE register operand with no registerReid Kleckner2016-02-162-6/+10
| | | | | | | | | | This apparently comes up when the register allocator decides that a variable will become undef along a certain path. Also improve the error message we emit when we can't map from LLVM register number to CV register number. llvm-svn: 261016
* [WebAssemly] Don't move calls or stores past intervening loadsDerek Schuff2016-02-161-0/+1
| | | | | | | | | | The register stackifier currently checks for intervening stores (and loads that may alias them) but doesn't account for the fact that the instruction being moved may affect intervening loads. Differential Revision: http://reviews.llvm.org/D17298 llvm-svn: 261014
* [LTO] Support StatisticsAdam Nemet2016-02-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: I thought -Xlinker -mllvm -Xlinker -stats worked at some point but maybe it never did. For clang, I believe that stats are printed from cc1_main. This patch also prints them for LTO, specifically right after codegen happens. I only looked at the C API for LTO briefly to see if this is a good place. Probably there are still cases where this wouldn't be printed but it seems to be working for the common case. I also experimented putting this in the LTOCodeGenerator destructor but that didn't trigger for me because ld64 does not destroy the LTOCodeGenerator. Reviewers: dexonsmith, joker.eph Subscribers: rafael, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17302 llvm-svn: 261013
* [codeview] Fix assertion on non-memory, non-register DBG_VALUE instructionsReid Kleckner2016-02-161-0/+7
| | | | | | | Eventually we should find a way to describe constant variables, but it is not obvious how to do this at the moment. llvm-svn: 261010
* [Hexagon] Adding relocation for code size, cold path optimization allowing a ↵Colin LeMahieu2016-02-1611-1/+70
| | | | | | | | | | | | 23-bit 4-byte aligned relocation to be a valid instruction encoding. The usual way to get a 32-bit relocation is to use a constant extender which doubles the size of the instruction, 4 bytes to 8 bytes. Another way is to put a .word32 and mix code and data within a function. The disadvantage is it's not a valid instruction encoding and jumping over it causes prefetch stalls inside the hardware. This relocation packs a 23-bit value in to an "r0 = add(rX, #a)" instruction by overwriting the source register bits. Since r0 is the return value register, if this instruction is placed after a function call which return void, r0 will be filled with an undefined value, the prefetch won't be confused, and the callee can access the constant value by way of the link register. llvm-svn: 261006
* [AArch64] Add pass to remove redundant copy after RAJun Bum Lim2016-02-164-0/+181
| | | | | | | | | | | | | | | | | | | | | Summary: This change will add a pass to remove unnecessary zero copies in target blocks of cbz/cbnz instructions. E.g., the copy instruction in the code below can be removed because the cbz jumps to BB1 when x0 is zero : BB0: cbz x0, .BB1 BB1: mov x0, xzr Jun Reviewers: gberry, jmolloy, HaoLiu, MatzeB, mcrosier Subscribers: mcrosier, mssimpso, haicheng, bmakam, llvm-commits, aemerson, rengolin Differential Revision: http://reviews.llvm.org/D16203 llvm-svn: 261004
* [GlobalISel] Re-apply r260922-260923 with MSVC-friendly code.Quentin Colombet2016-02-168-93/+166
| | | | | | | | | Original message: Get rid of the ifdefs in TargetLowering. Introduce a new API used only by GlobalISel: CallLowering. This API will contain target hooks dedicated to call lowering. llvm-svn: 260998
OpenPOWER on IntegriCloud