summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [dsymutil] Do not construct a StringRef from a std::string temporaryFrederic Riss2015-08-311-2/+1
| | | | llvm-svn: 246404
* [dsymutil] Implement -symtab/-s option.Frederic Riss2015-08-314-0/+237
| | | | | | | This option dumps the STAB entries that define the debug map(s) stored in the input binaries, and then exits. llvm-svn: 246403
* Support: Support LLVM_ENABLE_THREADS=0 in llvm/Support/thread.h.Peter Collingbourne2015-08-312-3/+33
| | | | | | | | Specifically, the header now provides llvm::thread, which is either a typedef of std::thread or a replacement that calls the function synchronously depending on the value of LLVM_ENABLE_THREADS. llvm-svn: 246402
* Turn resolution.s into an exhaustive testcase.Rafael Espindola2015-08-305-25/+534
| | | | | | | | | | | | | | Now that we print a symbol table and all symbol kinds are at least declared, we can test all combinations that don't produce an error. This also includes a few fixes to keep the test passing: * Keep the strong symbol in a weak X strong pair * Handle common symbols. The common X common case will be finished in a followup patch. llvm-svn: 246401
* [PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operandsHal Finkel2015-08-305-5/+1853
| | | | | | | | | | | | | | | | | | | | | | There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
* Suppress clang warnings in some testsEric Fiselier2015-08-309-28/+55
| | | | llvm-svn: 246399
* Traverse the SCoP to compute non-loop-carried domain conditionsJohannes Doerfert2015-08-3042-348/+946
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to compute domain conditions for conditionals we will now traverse the region in the ScopInfo once and build the domains for each block in the region. The SCoP statements can then use these constraints when they build their domain. The reason behind this change is twofold: 1) This removes a big chunk of preprocessing logic from the TempScopInfo, namely the Conditionals we used to build there. Additionally to moving this logic it is also simplified. Instead of walking the dominance tree up for each basic block in the region (as we did before), we now traverse the region only once in order to collect the domain conditions. 2) This is the first step towards the isl based domain creation. The second step will traverse the region similar to this step, however it will propagate back edge conditions. Once both are in place this conditional handling will allow multiple exit loops additional logic. Reviewers: grosser Differential Revision: http://reviews.llvm.org/D12428 llvm-svn: 246398
* [FIX] Keep a copy of the Domain set in the SCEVAffinatorJohannes Doerfert2015-08-301-4/+7
| | | | llvm-svn: 246397
* Do not store into a temporary twineTobias Grosser2015-08-301-2/+2
| | | | | | For some reason, this causes memory corruption issues. Let's just avoid it. llvm-svn: 246396
* Store scalar dependences from outside the scop into alloca locationsTobias Grosser2015-08-303-20/+41
| | | | | | | | | | | | We already modeled read-only dependences to scalar values defined outside the scop as memory reads and also generated read accesses from the corresponding alloca instructions that have been used to pass these scalar values around during code generation. However, besides for PHI nodes that have already been handled, we failed to store the orignal read-only scalar values into these alloc. This commit extends the initialization of scalar values to all read-only scalar values used within the scop. llvm-svn: 246394
* [OpenCL] Improve diagnostics detecting implicit vector conversion.Alexey Bader2015-08-303-2/+16
| | | | | | | | Reviewers: pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D12470 llvm-svn: 246393
* Remove task to get C++03 tests passing from TODO.txtEric Fiselier2015-08-302-2/+1
| | | | llvm-svn: 246392
* Fix test for Release builds, the label form is <label>:14, not <label>14.Yaron Keren2015-08-301-6/+6
| | | | llvm-svn: 246391
* getNewScalarValue: Get ScalarMap directly from member variable [NFC]Tobias Grosser2015-08-302-9/+5
| | | | | | | There is no need to pass the ScalarMap to getNewScalarValue as this map is (indirectly) used when calling getOrCreateScalarAlloca. llvm-svn: 246390
* createScalarInitialization: Always store PHI-node valueTobias Grosser2015-08-303-11/+7
| | | | | | | | | | | | | | | | | | | | | | | The current code really tries hard to use getNewScalarValue(), which checks if not the original value, but a possible copy or demoted value needs to be stored. In this calling context it seems, that we _always_ use the ScalarValue that comes from the incoming PHI node, but never any other value. As also no test cases fail, it seems right to just drop this call to getNewScalarValue and remove the parameters that are not needed any more. Johannes suggested that code like this might be needed for parallel code generation with offloading, but it was still unclear if/what exactly would be needed. As the parallel code generation does currently not support scalars at all, we will remove this code for now and add relevant code back when complitng the support of scalars in the parallel code generation. Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D12470 llvm-svn: 246389
* Ignore debug intrinsics and do not model their potential scalar metadata readsTobias Grosser2015-08-303-1/+14
| | | | | | | | | | Our code generation currently does not support scalar references to metadata values. Hence, it would crash if we try to model scalar dependences to metadata values. Fortunately, for one of the common uses, debug information, we can for now just ignore the relevant intrinsics and consequently the issue of how to model scalar dependences to metadata. llvm-svn: 246388
* Remove some code duplication [NFC]Tobias Grosser2015-08-302-43/+4
| | | | llvm-svn: 246387
* Minor code style improvement [NFC]Tobias Grosser2015-08-301-4/+3
| | | | llvm-svn: 246386
* Make test resistant to false matches of numbered (unnamed) labels inside ↵Yaron Keren2015-08-301-4/+9
| | | | | | | | | | | other numbers. In release builds labels are numbers. Matching just the number may result in false matches where the label is contained in other numbers, such as 14 inside [114 x i8]. A stricter match requiring start of line or > character before the label avoids these false matches. llvm-svn: 246385
* [OpenMP] Make the filetered clause iterator a real iterator and type safe.Benjamin Kramer2015-08-304-124/+110
| | | | | | | | | This replaces the filtered generic iterator with a type-specfic one based on dyn_cast instead of comparing the kind enum. This allows us to use range-based for loops and eliminates casts. No functionality change intended. llvm-svn: 246384
* Remove isNew from getOrCreateAllocaTobias Grosser2015-08-302-25/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit drops some dead code. Specifically, there is no need to initialize the virtual memory locations of scalars in BlockGenerator::handleOutsideUsers, the function that initalizes the escape map that keeps track of out-of-scope uses of scalar values. We already model instructions inside the scop that are used outside the scope (escaping instructions) as scalar memory writes at the position of the instruction. As a result, the virtual memory location of this instructions is already initialized when code-generating the corresponding virtual scalar write and consequently does not need to be initialized later on when generating the set of escaping values. Code references: In TempScopInfo::buildScalarDependences we detect scalar cross-statement dependences for all instructions (including PHIs) that have uses outside of the scop's region: // Check whether or not the use is in the SCoP. if (!R->contains(UseParent)) { AnyCrossStmtUse = true; continue; } We use this information in TempScopInfo::buildAccessFunctions were we build scalar write memory accesses for all these instructions: if (!isa<StoreInst>(Inst) && buildScalarDependences(Inst, &R, NonAffineSubRegion)) { // If the Instruction is used outside the statement, we need to build the // write access. IRAccess ScalarAccess(IRAccess::MUST_WRITE, Inst, ZeroOffset, 1, true, Inst); Functions.push_back(std::make_pair(ScalarAccess, Inst)); } Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D12472 llvm-svn: 246383
* Drop alias tags from vector test caseTobias Grosser2015-08-301-2/+4
| | | | | | They are not really part of what is tested here. llvm-svn: 246382
* NFC: Code style in VectorUtils.cppElena Demikhovsky2015-08-301-10/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D12478 llvm-svn: 246381
* Revert "Revert "New interface function is added to VectorUtils Value ↵Renato Golin2015-08-303-17/+44
| | | | | | | | | *getSplatValue(Value *Val);"" This reverts commit r246379. It seems that the commit was not the culprit, and the bot will be investigated for instability. llvm-svn: 246380
* Revert "New interface function is added to VectorUtils Value ↵Renato Golin2015-08-303-44/+17
| | | | | | | | | | *getSplatValue(Value *Val);" This reverts commit r246371, as it cause a rather obscure bug in AArch64 test-suite paq8p (time outs, seg-faults). I'll investigate it before reapplying. llvm-svn: 246379
* Stop calling the flat out insane ARM target parsing code unless theChandler Carruth2015-08-301-8/+20
| | | | | | | | | | | | | | | | | | | | | | | architecture string is something quite weird. Similarly delay calling the BPF parsing code, although that is more reasonable. To understand why I was motivated to make this change, it cuts the time for running the ADT TripleTest unittests by a factor of two in non-optimized builds (the developer default) and reduces my 'check-llvm' time by a full 15 seconds. The implementation of parseARMArch is *that* slow. I tried to fix it in the prior series of commits, but frankly, I have no idea how to finish fixing it. The entire premise of the function (to allow 'v7a-unknown-linux' or some such to parse as an 'arm-unknown-linux' triple) seems completely insane to me, but I'll let the ARM folks sort that out. At least it is now out of the critical path of every developer working on LLVM. It also will likely make some other folks' code significantly faster as I've heard reports of 2% of time spent in triple parsing even in optimized builds! I'm not done making this code faster, but I am done trying to improve the ARM target parsing code. llvm-svn: 246378
* 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
* Update for several APIs in LLVM that now use StringRefs rather thanChandler Carruth2015-08-304-23/+17
| | | | | | | | const char pointers. In turn, push this through Clang APIs as well, simplifying a number of bits of code that was handling the oddities of nullptrs. llvm-svn: 246375
* Teach the target parsing framework to directly compute the length of allChandler Carruth2015-08-305-96/+123
| | | | | | | | | | 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-303-0/+121
| | | | | | | | | | | | | 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-303-17/+44
| | | | | | | | | | | | | 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-303-222/+222
| | | | | | | | | | | | | | 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-302-204/+189
| | | | | | | | | | | | | 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
* Update for API change in LLVM: ARMTargetParser class is just the ARMChandler Carruth2015-08-303-22/+22
| | | | | | namespace. llvm-svn: 246368
* [Triple] Stop abusing a class to have only static methods and just useChandler Carruth2015-08-306-85/+75
| | | | | | | 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
* Remove some code duplication when creating Allocas [NFC]Tobias Grosser2015-08-292-22/+22
| | | | llvm-svn: 246364
* [X86] Reapplied r246204, r246206, r246211, r246223Simon Pilgrim2015-08-294-4/+136
| | | | | | | | (Re)added debug codegen test for F16C, FMA4, XOP + 3DNow! intrinsics Part of PR24590 llvm-svn: 246363
* [ELFv2] Implement R_X86_64_32 relocation.Davide Italiano2015-08-292-2/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D12436 llvm-svn: 246362
* [ARM] Fix up buildbots after r246360James Molloy2015-08-291-2/+2
| | | | | | I have no idea how I missed this in my internal testing. Just no idea. Sorry for the bot-armageddon. llvm-svn: 246361
* [ARM] Hoist fabs/fneg above a conversion to float.James Molloy2015-08-292-1/+57
| | | | | | | | | | | | | | | | | | 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
* [AST] Don't crash when comparing incomplete objectDavid Majnemer2015-08-292-1/+11
| | | | | | | | | | We cannot tell if an object is past-the-end if its type is incomplete. Zero sized objects satisfy past-the-end criteria and our object might turn out to be such an object. This fixes PR24622. llvm-svn: 246359
* AMDGPU: Add sdst operand to VOP2b instructionsMatt Arsenault2015-08-2918-108/+165
| | | | | | | | | | 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-292-11/+64
| | | | | | | | | | | | | 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
* Add a check for a function we're not testing.Eric Christopher2015-08-291-0/+1
| | | | llvm-svn: 246355
* 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
OpenPOWER on IntegriCloud