summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Remove a linear walk to find the default FPU for a given CPU by directlyChandler Carruth2015-08-301-7/+6
| | | | | | expanding the .def file within a StringSwitch. llvm-svn: 246377
* [MIR Serialization] static -> static const in ↵Hal Finkel2015-08-303-5/+5
| | | | | | | | | getSerializable*MachineOperandTargetFlags Make the arrays 'static const' instead of just 'static'. Post-commit review comment from Roman Divacky on IRC. NFC. llvm-svn: 246376
* Teach the target parsing framework to directly compute the length of allChandler Carruth2015-08-302-45/+72
| | | | | | | | | | of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
* [PowerPC/MIR Serialization] Target flags serialization supportHal Finkel2015-08-302-0/+41
| | | | | | | | | | | | | Add support for MIR serialization of PowerPC-specific operand target flags (based on the generic infrastructure added in r244185 and r245383). I won't even pretend that this is good test coverage, but this includes the regression test associated with r246372. Adding an MIR test for that fix is far superior to adding an IR-level test because particular instruction-scheduling decisions are necessary in order to expose the bug, and using an MIR test we can start the pipeline post-scheduling. llvm-svn: 246373
* [PowerPC] Don't assume ADDISdtprelHA's source is r3Hal Finkel2015-08-301-5/+5
| | | | | | | | | | | | Even through ADDISdtprelHA generally has r3 as its source register, it is possible for the instruction scheduler to move things around such that some other register is the source. We need to print the actual source register, not always r3. Fixes PR24394. The test case will come in a follow-up commit because it depends on MIR target-flags parsing. llvm-svn: 246372
* New interface function is added to VectorUtilsElena Demikhovsky2015-08-302-17/+39
| | | | | | | | | | | | | Value *getSplatValue(Value *Val); It complements the CreateVectorSplat(), which creates 2 instructions - insertelement and shuffle with all-zero mask. The new function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr). It also returns a splat value form ConstantDataVector, for completeness. Differential Revision: http://reviews.llvm.org/D11124 llvm-svn: 246371
* Refactor the ARM target parsing to use a def file with macros to expandChandler Carruth2015-08-301-164/+14
| | | | | | | | | | | | | | the necessary tables. This will allow me to restructure the code and structures using this to be significantly more efficient. It also removes the duplication of the list of several enumerators. It also enshrines that the order of enumerators match the order of the entries in the tables, something the implementation code actually uses. No functionality changed (yet). llvm-svn: 246370
* [Triple] Use clang-format to normalize the formatting of the ARM targetChandler Carruth2015-08-301-36/+35
| | | | | | | | | | | | | parsing logic prior to making substantial changes to it. This parsing logic is incredibly wasteful, so I'm planning to rewrite it. Just unittesting the triple parsing logic spends well over 80% of its time in the ARM parsing logic, and others have measured significant time spent here in real production compiles. Stay tuned... llvm-svn: 246369
* [Triple] Stop abusing a class to have only static methods and just useChandler Carruth2015-08-305-49/+49
| | | | | | | the namespace that we are already using for the enums that are produced by the parsing. llvm-svn: 246367
* SelectionDAG: add missing ComputeSignBits case for SELECT_CCFiona Glaser2015-08-291-0/+5
| | | | | | Identical to SELECT, just with different operand numbers. llvm-svn: 246366
* Fix shared library build.Peter Collingbourne2015-08-291-0/+7
| | | | llvm-svn: 246365
* [ARM] Hoist fabs/fneg above a conversion to float.James Molloy2015-08-291-1/+16
| | | | | | | | | | | | | | | | | | This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
* AMDGPU: Add sdst operand to VOP2b instructionsMatt Arsenault2015-08-292-20/+30
| | | | | | | | | | The VOP3 encoding of these allows any SGPR pair for the i1 output, but this was forced before to always use vcc. This doesn't yet try to use this, but does add the operand to the definitions so the main change is adding vcc to the output of the VOP2 encoding. llvm-svn: 246358
* AMDGPU: Set mem operands for spill instructionsMatt Arsenault2015-08-293-25/+55
| | | | llvm-svn: 246357
* AMDGPU: Fix dropping mem operands when moving to VALUMatt Arsenault2015-08-291-11/+12
| | | | | | | | | | | | | Without a memory operand, mayLoad or mayStore instructions are treated as hasUnorderedMemRef, which results in much worse scheduling. We really should have a verifier check that any non-side effecting mayLoad or mayStore has a memory operand. There are a few instructions (interp and images) which I'm not sure what / where to add these. llvm-svn: 246356
* AMDGPU/SI: Fix some invaild assumptions when folding 64-bit immediatesTom Stellard2015-08-291-1/+5
| | | | | | | | | | | | | | | Summary: We were assuming tha if the use operand had a sub-register that the immediate was 64-bits, but this was breaking the case of folding a 64-bit immediate into another 64-bit instruction. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12255 llvm-svn: 246354
* AMDGPU/SI: Factor operand folding code into its own functionTom Stellard2015-08-281-67/+79
| | | | | | | | | | Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12254 llvm-svn: 246353
* DI: Set DILexicalBlock columns >= 65536 to 0/unknownDuncan P. N. Exon Smith2015-08-281-0/+3
| | | | | | | | | This fixes PR24621 and matches what we do for `DILocation`. Although the limit seems somewhat artificial, there are places in the backend that also assume 16-bit columns, so we may as well just be consistent about the limits. llvm-svn: 246349
* [X86] NFC: Clean up and clang-format a few linesVedant Kumar2015-08-281-5/+5
| | | | llvm-svn: 246340
* DI: Add Function::getSubprogram()Duncan P. N. Exon Smith2015-08-282-1/+21
| | | | | | | | | | | | | | | | | | Add `Function::setSubprogram()` and `Function::getSubprogram()`, convenience methods to forward to `setMetadata()` and `getMetadata()`, respectively, and deal in `DISubprogram` instead of `MDNode`. Also add a verifier check to enforce that `!dbg` attachments are always subprograms. Originally (when I had the llvm-dev discussion back in April) I thought I'd store a pointer directly on `llvm::Function` for these attachments -- we frequently have debug info, and that's much cheaper than using map in the context if there are no other function-level attachments -- but for now I'm just using the generic infrastructure. Let's add the extra complexity only if this shows up in a profile. llvm-svn: 246339
* AsmPrinter: Allow null subroutine typeDuncan P. N. Exon Smith2015-08-282-8/+3
| | | | | | | | | | | | | | | | | | | | | | Currently the DWARF backend requires that subprograms have a type, and the type is ignored if it has an empty type array. The long term direction here -- see PR23079 -- is instead to skip the type entirely if there's no valid type. It turns out we have cases in tree of missing types on subprograms, but since they're not referenced by compile units, the backend never crashes on them. One option would be to add a Verifier check that subprograms have types, and fix the bitrot. However, this is a fair bit of churn (20-30 testcases) that would be reversed anyway by PR23079. I found this inconsistency because of a WIP patch and upgrade script for PR23367 that started crashing on test/DebugInfo/2010-10-01-crash.ll. This commit updates the testcase to reference the subprogram from the compile unit, and fixes the resulting crash (in line with the direction of PR23079). This also updates `DIBuilder` to stop assuming a non-null pointer for the subroutine types. llvm-svn: 246333
* Revert r246232 and r246304.David Majnemer2015-08-282-14/+51
| | | | | | | | | This reverts isSafeToSpeculativelyExecute's use of ReadNone until we split ReadNone into two pieces: one attribute which reasons about how the function reasons about memory and another attribute which determines how it may be speculated, CSE'd, trap, etc. llvm-svn: 246331
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-283-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* [InstCombine] Fix PR24605.Sanjoy Das2015-08-282-0/+11
| | | | | | | | | | | | | | PR24605 is caused due to an incorrect insert point in instcombine's IR builder. When simplifying %t = add X Y ... %m = icmp ... %t the replacement for %t should be placed before %t, not before %m, as there could be a use of %t between %t and %m. llvm-svn: 246315
* Optimize memcmp(x,y,n)==0 for small n and suitably aligned x/y.Chad Rosier2015-08-281-0/+22
| | | | | | | http://reviews.llvm.org/D6952 PR20673 llvm-svn: 246313
* [mips64][mcjit] Add N64R6 relocations tests and fix N64R2 testsPetar Jovanovic2015-08-281-2/+2
| | | | | | | | | | | | This patch adds a test for MIPS64R6 relocations, it corrects check expressions for R_MIPS_26 and R_MIPS_PC16 relocations in MIPS64R2 test, and it adds run for big endian in MIPS64R2 test. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D11217 llvm-svn: 246311
* [mips] Remove incorrect DebugLoc entries from prologuePetar Jovanovic2015-08-283-4/+3
| | | | | | | | | | This has been causing the prologue_end to be incorrectly positioned. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D11293 llvm-svn: 246309
* Make MergeConsecutiveStores look at other stores on same chainMatt Arsenault2015-08-281-24/+149
| | | | | | | | | | | | | | | | | | | | | | | | | When combiner AA is enabled, look at stores on the same chain. Non-aliasing stores are moved to the same chain so the existing code fails because it expects to find an adajcent store on a consecutive chain. Because of how DAGCombiner tries these store combines, MergeConsecutiveStores doesn't see the correct set of stores on the chain when it visits the other stores. Each store individually has its chain fixed before trying to merge consecutive stores, and then tries to merge stores from that point before the other stores have been processed to have their chains fixed. To fix this, attempt to use FindBetterChain on any possibly neighboring stores in visitSTORE. Suppose you have 4 32-bit stores that should be merged into 1 vector store. One store would be visited first, fixing the chain. What happens is because not all of the store chains have yet been fixed, 2 of the stores are merged. The other 2 stores later have their chains fixed, but because the other stores were already merged, they have different memory types and merging the two different sized stores is not supported and would be more difficult to handle. llvm-svn: 246307
* Remove Merge Functions pointer comparisonsJF Bastien2015-08-281-17/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes two remaining places where pointer value comparisons are used to order functions: comparing range annotation metadata, and comparing block address constants. (These are both rare cases, and so no actual non-determinism was observed from either case). The fix for range metadata is simple: the annotation always consists of a pair of integers, so we just order by those integers. The fix for block addresses is more subtle. Two constants are the same if they are the same basic block in the same function, or if they refer to corresponding basic blocks in each respective function. Note that in the first case, merging is trivially correct. In the second, the correctness of merging relies on the fact that the the values of block addresses cannot be compared. This change is actually an enhancement, as these functions could not previously be merged (see merge-block-address.ll). There is still a problem with cross function block addresses, in that constants pointing to a basic block in a merged function is not updated. This also more robustly compares floating point constants by all fields of their semantics, and fixes a dyn_cast/cast mixup. Author: jrkoenig Reviewers: dschuff, nlewycky, jfb Subscribers llvm-commits Differential revision: http://reviews.llvm.org/D12376 llvm-svn: 246305
* [CodeGen] isInTailCallPosition didn't consider readnone tailcallsDavid Majnemer2015-08-282-13/+12
| | | | | | | | | | A readnone tailcall may still have a chain of computation which follows it that would invalidate a tailcall lowering. Don't skip the analysis in such cases. This fixes PR24613. llvm-svn: 246304
* [x86] enable machine combiner reassociations for scalar 'and' instsSanjay Patel2015-08-281-1/+5
| | | | llvm-svn: 246300
* [SROA] Fix PR24463, a crash I introduced in SROA by allowing it toChandler Carruth2015-08-281-3/+13
| | | | | | | | | | | | handle more allocas with loads past the end of the alloca. I suspect there are some related crashers with slightly different patterns, but I'll fix those and add test cases as I find them. Thanks to David Majnemer for the excellent test case reduction here. Made this super simple to debug and fix. llvm-svn: 246289
* Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-281-1/+4
| | | | | | | | | | | short import files This patch includes a fix for a llvm-readobj test. With this patch, the tool does no longer print out COFF headers for the short import file, but that's probably desirable because the header for the short import file is dummy. llvm-svn: 246283
* Revert r246244 and r246243Steven Wu2015-08-283-117/+13
| | | | | | These two commits cause clang/llvm bootstrap to hang. llvm-svn: 246279
* Rollback r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-281-46/+1
| | | | | | | | short import files This change caused a test for llvm-readobj to fail. llvm-svn: 246277
* Object: Teach llvm-ar to create symbol table for COFF short import files.Rui Ueyama2015-08-281-1/+46
| | | | | | | | | | | | | COFF short import files are special kind of files that contains only DLL-exported symbol names. That's different from object files because it has no data except symbol names. This change implements a SymbolicFile interface for the short import files so that symbol names can be accessed through that interface. llvm-ar is now able to read the file and create symbol table entries for short import files. llvm-svn: 246276
* LLVMCodeGen: Update libdeps corresponding to r246236.NAKAMURA Takumi2015-08-281-1/+1
| | | | llvm-svn: 246274
* [CodeGen] Support (and default to) expanding READCYCLECOUNTER to 0.Ahmed Bougacha2015-08-285-30/+49
| | | | | | | | | | | For targets that didn't support this, this will let us respect the langref instead of failing to select. Note that we don't need to change the 32-bit x86/PPC lowerings (to account for the result type/# difference) because they're both custom and bypass type legalization. llvm-svn: 246258
* [WinEH] Update coloring to handle nested cases cleanlyJoseph Tremoulet2015-08-281-70/+114
| | | | | | | | | | | | | | | | | | | | | | | Summary: Change the coloring algorithm in WinEHPrepare to visit a funclet's exits in its parents' contexts and so properly classify the continuations of nested funclets. Also change the placement of cloned blocks to be deterministic and to maintain the relative order of each funclet's blocks. Add a lit test showing various patterns that require cloning, the last several of which don't have CHECKs yet because they require cloning entire funclets which is NYI. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12353 llvm-svn: 246245
* Constant propagation after hitting assume(cmp) bugfixPiotr Padlewski2015-08-283-11/+50
| | | | | | | | | Last time code run into assertion `BBE.isSingleEdge()` in lib/IR/Dominators.cpp:200. http://reviews.llvm.org/D12170 llvm-svn: 246244
* Constant propagation after hiting llvm.assumePiotr Padlewski2015-08-281-3/+68
| | | | | | | | | | | After hitting @llvm.assume(X) we can: - propagate equality that X == true - if X is icmp/fcmp (with eq operation), and one of operand is constant we can change all variables with constants in the same BasicBlock http://reviews.llvm.org/D11918 llvm-svn: 246243
* Fix: CFLAA -- Mark no-args returns as unknownGeorge Burgess IV2015-08-281-0/+10
| | | | | | | | | | | | | | Prior to this patch, we hadn't been marking StratifiedSets with the appropriate StratifiedAttrs when handling the result of no-args call instructions. This caused us to report NoAlias when handed, for example, an escaped alloca and a result from an opaque function. Now we properly mark the return value of said functions. Thanks again to Chandler, Richard, and Nick for pinging me about this. Differential review: http://reviews.llvm.org/D12408 llvm-svn: 246240
* [AArch64][CollectLOH] Fix a regression that prevented us to detect chains ofQuentin Colombet2015-08-271-2/+6
| | | | | | | | | | | more than 2 instructions. I introduced this regression a while back and did not noticed it because I somehow forgot to push the initial test cases for the pass! Fix that as well! llvm-svn: 246239
* CodeGen: Introduce splitCodeGen and teach LTOCodeGenerator to use it.Peter Collingbourne2015-08-273-13/+111
| | | | | | | | | | | | | | | llvm::splitCodeGen is a function that implements the core of parallel LTO code generation. It uses llvm::SplitModule to split the module into linkable partitions and spawning one code generation thread per partition. The function produces multiple object files which can be linked in the usual way. This has been threaded through to LTOCodeGenerator (and llvm-lto for testing purposes). Separate patches will add parallel LTO support to the gold plugin and lld. Differential Revision: http://reviews.llvm.org/D12260 llvm-svn: 246236
* [WinEH] Add some support for code generating catchpadReid Kleckner2015-08-2730-84/+193
| | | | | | | We can now run 32-bit programs with empty catch bodies. The next step is to change PEI so that we get funclet prologues and epilogues. llvm-svn: 246235
* [ValueTracking] readnone CallInsts are fair game for speculationDavid Majnemer2015-08-271-39/+3
| | | | | | | | | | Any call which is side effect free is trivially OK to speculate. We already had similar logic in EarlyCSE and GVN but we were missing it from isSafeToSpeculativelyExecute. This fixes PR24601. llvm-svn: 246232
* [CodeGen] Check FoldConstantArithmetic result before using it.Ahmed Bougacha2015-08-271-2/+3
| | | | | | | | Fixes PR24602: r245689 introduced an unguarded use of SelectionDAG::FoldConstantArithmetic, which returns 0 when it fails because of opaque (hoisted) constants. llvm-svn: 246217
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-37/+55
| | | | | | | | | | | | Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246194
* Revert 246186; still breaks on some systemsErik Schnetter2015-08-271-55/+37
| | | | llvm-svn: 246191
* Improve vectorization diagnostic messages and extend vectorize(enable) pragma.Tyler Nowicki2015-08-271-15/+25
| | | | | | | | | | | | | | | | This patch changes the analysis diagnostics produced when loops with floating-point recurrences or memory operations are identified. The new messages say "cannot prove it is safe to reorder * operations; allow reordering by specifying #pragma clang loop vectorize(enable)". Depending on the type of diagnostic the message will include additional options such as ffast-math or __restrict__. This patch also allows the vectorize(enable) pragma to override the low pointer memory check threshold. When the hint is given a higher threshold is used. See the clang patch for the options produced for each diagnostic. llvm-svn: 246187
OpenPOWER on IntegriCloud