summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* [mips] Refactor calls to setCanHaveModuleDir.Toma Tabacu2014-08-132-133/+55
| | | | | | | | | | | | | | | | | Summary: Moved some calls to setCanHaveModuleDir to the MipsTargetStreamer base class and removed the resulting empty functions from the MipsTargetELFStreamer class. Also fixed a missing call to setCanHaveModuleDir in MipsTargetELFStreamer::emitDirectiveSetMicroMips. Reviewers: dsanders Reviewed By: dsanders Subscribers: tomatabacu Differential Revision: http://reviews.llvm.org/D4781 llvm-svn: 215542
* [shuffle] Stand back! I'm about to (try to) do math!Chandler Carruth2014-08-131-2/+39
| | | | | | | | | | | | | | | | | | | Especially with blends and large tree heights there was a problem with the fuzzer where it would end up with enough undef shuffle elements in enough parts of the tree that in a birthday-attack kind of way we ended up regularly having large numbers of undef elements in the result. I was seeing reasonably frequent cases of *all* results being undef which prevents us from doing any correctness checking at all. While having undef lanes is important, this was too much. So I've tried to apply some math to the probabilities of having an undef lane and balance them against the tree height. Please be gentle, I'm really terrible at math. I probably made a bunch of amateur mistakes here. Fixes, etc. are quite welcome. =D At least in running it some, it seems to be producing more interesting (for correctness testing) results. llvm-svn: 215540
* Asserting that the call to chdir succeeds in this test. Fixes some ↵Aaron Ballman2014-08-131-2/+2
| | | | | | -Wunused-result warnings. llvm-svn: 215539
* [optnone] Make the optnone attribute effective at suppressing functionChandler Carruth2014-08-132-7/+37
| | | | | | | | | | | | | attribute and function argument attribute synthesizing and propagating. As with the other uses of this attribute, the goal remains a best-effort (no guarantees) attempt to not optimize the function or assume things about the function when optimizing. This is particularly useful for compiler testing, bisecting miscompiles, triaging things, etc. I was hitting specific issues using optnone to isolate test code from a test driver for my fuzz testing, and this is one step of fixing that. llvm-svn: 215538
* Silence a -Wparenthesis warning with these asserts. NFC.Aaron Ballman2014-08-131-2/+2
| | | | llvm-svn: 215537
* [SKX] Extended non-temporal load/store instructions for AVX512VL subsets.Robert Khasanov2014-08-137-36/+391
| | | | | | | | | Added avx512_movnt_vl multiclass for handling 256/128-bit forms of instruction. Added encoding and lowering tests. Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 215536
* Re-commit: [mips] Implement .ent, .end, .frame, .mask and .fmask.Daniel Sanders2014-08-135-22/+369
| | | | | | | | | | | Patch by Matheus Almeida and Toma Tabacu The lld test failure on the previous attempt to commit was caused by the addition of the .pdr section causing the offsets it was checking to change. This has been fixed by removing the .ent/.end directives from that test since they weren't really needed. llvm-svn: 215535
* [shuffle] Make the seed an optional component and add support forChandler Carruth2014-08-131-2/+3
| | | | | | letting the python very directly compute a UUID. llvm-svn: 215533
* Revert r215415 which causse MSan to crash on a great deal of C++ code.Chandler Carruth2014-08-132-23/+0
| | | | | | I've followed up on the original commit as well. llvm-svn: 215532
* [shuffle] Teach the shuffle fuzzer to fuzz blends, including formingChandler Carruth2014-08-131-39/+67
| | | | | | | | | | | | | | | | | a tree of inputs to blend iteratively together. This required a pretty substantial rewrite of the innards. The number of shuffle instructions is now bounded in terms of tree-height. There is a flag to disable blends so that its still possible to test single input shuffles. I've also improved various aspects of how the test program is generated, primarily to simplify the test harness and allow some optimizations to clean up how we actually check the results and build up the inputs. Again, apologies for my likely horrible use of Python... But hey, it works! (Ish?) llvm-svn: 215530
* AVX-512: Fixed a bug in shufflevector lowering.Elena Demikhovsky2014-08-132-1/+20
| | | | | | | PALIGNR instruction does not exist in AVX-512F set. Added a test. llvm-svn: 215526
* InstCombine: Combine (xor (or %a, %b) (xor %a, %b)) to (add %a, %b)Karthik Bhat2014-08-132-0/+23
| | | | | | | | | | | | | Correctness proof of the transform using CVC3- $ cat t.cvc A, B : BITVECTOR(32); QUERY BVXOR(A | B, BVXOR(A,B) ) = A & B; $ cvc3 t.cvc Valid. llvm-svn: 215524
* [NVPTX] Remove MemIntrinsicSDNode/MemSDNode duplicate checkingHal Finkel2014-08-131-7/+0
| | | | | | | | | | | As of r214452, isa<MemSDNode> will return true for nodes for which isa<MemIntrinsicSDNode> will return true (classof now respects the actual class hierarchy). So we no longer need to check for both MemIntrinsicSDNode and MemSDNode separately. No functionality change intended. llvm-svn: 215523
* Fix examples of "named metadata" (some of which isn't named).Nick Lewycky2014-08-131-2/+2
| | | | llvm-svn: 215522
* [shuffle] Tweak the shuffle fuzzer to support bigger seeds. I'mChandler Carruth2014-08-131-6/+6
| | | | | | currently using UUIDs to seed this in order to scan a bigger range. llvm-svn: 215521
* [x86] Rewrite a core part of the new vector shuffle lowering to handleChandler Carruth2014-08-132-22/+141
| | | | | | | | | | | | | | | | | | | | one pesky test case correctly. This test case caused the old code to infloop occilating between solving the low-half and the high-half. The 'side balancing' part of single-input v8 shuffle lowering didn't handle the one pattern which can cause it to occilate. Fortunately the fuzz testing found this case. Unfortuately it was *terrible* to handle. I'm really sorry for the amount and density of the code here, I'd love suggestions on how to simplify it. I feel like there *must* be a simpler form here, but after a lot of days I've not found it. This is the only one I've found that even works. I've added the one pesky test case along with some nice comments explaining the core problem that we have to solve here. So far this has survived approximately 32k test cases. More strenuous fuzzing commencing. llvm-svn: 215519
* [PowerPC] Implement PPCTargetLowering::getTgtMemIntrinsicHal Finkel2014-08-137-5/+92
| | | | | | | | | | | | | | | | | This implements PPCTargetLowering::getTgtMemIntrinsic for Altivec load/store intrinsics. As with the construction of the MachineMemOperands for the intrinsic calls used for unaligned load/store lowering, the only slight complication is that we need to represent a larger memory range than the loaded/stored value-type size (because the address is rounded down to an aligned address, and we need to conservatively represent the entire possible range of the actual access). This required adding an extra size field to TargetLowering::IntrinsicInfo, and this was done in a way that required no modifications to other targets (the size defaults to the store size of the provided memory data type). This fixes test/CodeGen/PowerPC/unal-altivec-wint.ll (so it can be un-XFAILed). llvm-svn: 215512
* Fix classof for ISD::INTRINSIC_W_CHAIN and INTRINSIC_VOIDHal Finkel2014-08-133-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, our use of the SDNode class hierarchy for INTRINSIC_W_CHAIN and INTRINSIC_VOID nodes is somewhat broken right now. These nodes sometimes are used for memory intrinsics (those with MachineMemOperands), and sometimes not. When not, the nodes are not created as instances of MemIntrinsicSDNode, but rather created as some other subclass of SDNode using DAG::getNode. When they are memory intrinsics, they are created using DAG::getMemIntrinsicNode as instances of MemIntrinsicSDNode. MemIntrinsicSDNode is a subclass of MemSDNode, but prior to r214452, we had a non-self-consistent setup whereby MemIntrinsicSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID would return true but MemSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID would return false. In r214452, MemSDNode::classof was changed to return true for INTRINSIC_W_CHAIN and INTRINSIC_VOID, which is now self-consistent. The problem is that neither the pre-r214452 logic and the post-r214452 logic are really right. The truth is that not all INTRINSIC_W_CHAIN and INTRINSIC_VOID nodes are instances of MemIntrinsicSDNode (or MemSDNode for that matter), and the return value from classof needs to reflect that. This was broken before r214452 (because MemIntrinsicSDNode::classof always returned true), and was broken afterward (because MemSDNode::classof also always returned true), and will now be correct. The minimal solution is to grab one of the SubclassData bits (there is one left for MemIntrinsicSDNode nodes) and use it to store whether or not a particular INTRINSIC_W_CHAIN or INTRINSIC_VOID is really an instance of MemIntrinsicSDNode or not. Doing this allows both MemIntrinsicSDNode::classof and MemSDNode::classof to return the correct answer for the underlying object for both the memory-intrinsic and non-memory-intrinsic cases. This fixes the problem that r214452 created in the SelectionDAGDumper (thanks to Matt Arsenault for pointing it out). Because PowerPC does not implement getTgtMemIntrinsic, this change breaks test/CodeGen/PowerPC/unal-altivec-wint.ll. I've XFAILed it for now, and will fix it in a follow-up commit. llvm-svn: 215511
* [AVX512] Verify the code generated for the intrinsic _mm512_broadcastsd_pdAdam Nemet2014-08-131-0/+18
| | | | llvm-svn: 215487
* Fix -Wsign-compare warningsDavid Blaikie2014-08-121-3/+3
| | | | llvm-svn: 215483
* APInt: Make self-move-assignment a no-op to fix stage3 clang-clReid Kleckner2014-08-122-2/+28
| | | | | | | | | | | | | | | | | | | | | | It's not clear what the semantics of a self-move should be. The consensus appears to be that a self-move should leave the object in a moved-from state, which is what our existing move assignment operator does. However, the MSVC 2013 STL will perform self-moves in some cases. In particular, when doing a std::stable_sort of an already sorted APSInt vector of an appropriate size, one of the merge steps will self-move half of the elements. We don't notice this when building with MSVC, because MSVC will not synthesize the move assignment operator for APSInt. Presumably MSVC does this because APInt, the base class, has user-declared special members that implicitly delete move special members. Instead, MSVC selects the copy-assign operator, which defends against self-assignment. Clang, on the other hand, selects the move-assign operator, and we get garbage APInts. llvm-svn: 215478
* Remove a condition that can never be true, as wittnessed by the assertAdrian Prantl2014-08-121-3/+2
| | | | | | above. llvm-svn: 215477
* [AVX512] Handle valign masking intrinsic via C++ loweringAdam Nemet2014-08-123-16/+25
| | | | | | | | | | | | | | I think that this will scale better in most cases than adding a Pat<> for each mapping from the intrinsic DAG to the intruction (i.e. rri, rrik, rrikz). We can just lower to the SDNode and have the resulting DAG be matches by the DAG patterns. Alternatively (long term), we could keep the Pat<>s but generate them via the new AVX512_masking multiclass. The difficulty is that in order to formulate that we would have to concatenate DAGs. Currently this is only supported if the operators of the input DAGs are identical. llvm-svn: 215473
* Allwo bitcast + struct GEP transform to work with addrspacecastMatt Arsenault2014-08-123-3/+48
| | | | llvm-svn: 215467
* R600: Use optimized 24bit path in udivremJan Vesely2014-08-123-18/+283
| | | | | | | | | v2: drop enum keyword use correct extension mode don't bother computing the sign in unsinged case Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> llvm-svn: 215462
* R600: Remove unused code.Jan Vesely2014-08-122-174/+0
| | | | | Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> llvm-svn: 215461
* R600: Use i24 optimized path for SREMJan Vesely2014-08-123-8/+146
| | | | | | | | | v2: add tests rename LowerSDIV24 to LowerSDIVREM24 handle the rem part in this function Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> llvm-svn: 215460
* Fix a parentheses warning introduced in r215394.Quentin Colombet2014-08-121-2/+2
| | | | llvm-svn: 215459
* Don't upgrade global constructors when reading bitcodeDuncan P. N. Exon Smith2014-08-125-56/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An optional third field was added to `llvm.global_ctors` (and `llvm.global_dtors`) in r209015. Most of the code has been changed to deal with both versions of the variables. Users of the C API might create either version, the helper functions in LLVM create the two-field version, and clang now creates the three-field version. However, the BitcodeReader was changed to always upgrade to the three-field version. This created an unnecessary inconsistency in the IR before/after serializing to bitcode. This commit resolves the inconsistency by making the third field truly optional (and not upgrading in the bitcode reader). Since `llvm-link` was relying on this upgrade code, rather than deleting it I've moved it into `ModuleLinker`, where it upgrades these arrays as necessary to resolve inconsistencies between modules. The ideal resolution would be to remove the 2-field version and make the third field required. I filed PR20506 to track that. I changed `test/Bitcode/upgrade-global-ctors.ll` to a negative test and duplicated the `llvm-link` check in `test/Linker/global_ctors.ll` to check both upgrade directions. Since I came across this as part of PR5680 (serializing use-list order), I've also added the missing `verify-uselistorder` RUN line to `test/Bitcode/metadata-2.ll`. llvm-svn: 215457
* fixed typosSanjay Patel2014-08-121-5/+5
| | | | llvm-svn: 215451
* Make the test a bit more strict.Rafael Espindola2014-08-121-2/+2
| | | | | | | Before it would pass even if @b or @c ended up pointing to a variable named @a123. llvm-svn: 215450
* Add a plugin testcase for merging weak variables.Rafael Espindola2014-08-122-0/+18
| | | | | | | | | I initially thought I could implement COMDATs with aliases by just internalizing GVs instead of dropping them. This is a counter example: Internalizing one of the @a would make @b and @c point to different variables. llvm-svn: 215447
* llvm/test/TableGen/*Foreach*.td: Remove XFAIL:vg_leak. They have not been ↵NAKAMURA Takumi2014-08-124-4/+0
| | | | | | failing since r215176. llvm-svn: 215445
* Reverted my "Testing commit access" commit.Toma Tabacu2014-08-121-0/+1
| | | | llvm-svn: 215441
* Testing commit access.Toma Tabacu2014-08-121-1/+0
| | | | llvm-svn: 215440
* llvm-objdump: print contents of MachO __unwind_info sectionsTim Northover2014-08-125-11/+306
| | | | llvm-svn: 215437
* Have MachineRegisterInfo take and store the MachineFunction itEric Christopher2014-08-123-7/+7
| | | | | | | | was created for rather than the TargetMachine since we only needed the TM for the subtarget and we can get that from the MF. llvm-svn: 215432
* [MachineCombiner] Fix for ICE bug 20598Gerolf Hoflehner2014-08-122-1/+108
| | | | | | | | | | | | | | | | | | The combiner ignored DBG nodes when checking the uses of a virtual register. It combined a sequence like %vreg1 = madd %vreg2, %vreg3,... DBG_VALUE (%vreg1 ...) %vreg4 = add %vreg1,... to %vreg4 = madd %vreg2, %vreg3 leaving behind a dangling DBG_VALUE with a definition. This triggered an assertion in the MachineTraceMetrics.cpp module. llvm-svn: 215431
* IR: Print a newline when dumping TypesJustin Bogner2014-08-123-4/+4
| | | | | | | | | | | | Type::dump() doesn't print a newline, which makes for a poor experience in a debugger. This looks like it was an ommission considering Value::dump() two lines above, so I've changed Type to add a newline as well. Of the two in-tree callers, one added a newline anyway, and I've updated the other one to use Type::print instead. llvm-svn: 215421
* [OCaml] Expose Llvm.get_operand_use.Peter Zotov2014-08-123-0/+11
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com> llvm-svn: 215420
* [LLVM-C] Expose User::getOperandUse as LLVMGetOperandUse.Peter Zotov2014-08-122-0/+12
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com> llvm-svn: 215419
* DebugLocEntry: Restore the comparison predicate from before theAdrian Prantl2014-08-122-1/+5
| | | | | | | | | refactoring in 215384. This way it can unique multiple entries describing the same piece even if they don't have the exact same location. (The same piece may get merged in and be added from OpenRanges). There ought to be a more elegant solution for this, though. llvm-svn: 215418
* msan: Handle musttail callsReid Kleckner2014-08-122-0/+23
| | | | | | | | | | | | | | | | First, avoid calling setTailCall(false) on musttail calls. The funciton prototypes should be "congruent", so the shadow layout should be exactly the same. Second, avoid inserting instrumentation after a musttail call to propagate the return value shadow. We don't need to propagate the result of a tail call, it should already be in the right place. Reviewed By: eugenis Differential Revision: http://reviews.llvm.org/D4331 llvm-svn: 215415
* Move helper for getting a terminating musttail call to BasicBlockReid Kleckner2014-08-123-30/+45
| | | | | | | | | | | No functional change. To be used in future commits that need to look for such instructions. Reviewed By: rafael Differential Revision: http://reviews.llvm.org/D4504 llvm-svn: 215413
* Revert "Partially revert r214761 that asserted that all concrete debug info ↵David Blaikie2014-08-121-3/+1
| | | | | | | | | | | variables had DIEs, due to a failure on Darwin." I believe this was addressed by r215157 and r215227, so let's have another go at the bots, etc. This reverts commit r214880. llvm-svn: 215412
* [MachineSink] Improve the compile time by preserving the dominance informationQuentin Colombet2014-08-111-39/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as long as possible. ** Context ** Each time the dominance information is modified, the dominator tree analysis switches in a slow query mode. After a few queries without any modification on the dominator tree, it performs an expensive update of its internal structure to provide fast queries again. ** Problem ** Prior to this patch, the MachineSink pass was splitting the critical edges on demand while relying heavy on the dominator tree information. In some cases, this leads to pathological behavior where: - We end up in the slow query mode right after splitting an edge. - We update the dominance information. - We break the dominance information again, thus ending up in the slow query mode and so on. ** Proposed Solution ** To mitigate this effect, this patch postpones all the splitting of the edges at the end of each iteration of the main loop. The benefits are: - The dominance information is valid for the life time of an iteration. - This simplifies the code as we do not have to special treat instructions that are sunk on critical edges. Indeed, the related block will be available through the next iteration. The downside is that when edges splitting is required, this incurs an additional iteration of the main loop compared to the previous scheme. ** Performance ** Thanks to this patch, the motivating example compiles in 6+ minutes instead of 10+ minutes. No test case added as the motivating example as nothing special but being huge! I have measured only noise for both the compile time and the runtime on the llvm test-suite + SPECs with Os and O3. Note: The current implementation of MachineBasicBlock::SplitCriticalEdge also uses the dominance information and therefore, hits this problem. A subsequent patch will address that. <rdar://problem/17894619> llvm-svn: 215410
* [x86] Fold extract_vector_elt of a load into the Load's address computation.Michael J. Spencer2014-08-112-91/+144
| | | | llvm-svn: 215409
* Add a couple of convenience accessors to DebugLocEntry::Value to furtherAdrian Prantl2014-08-112-13/+12
| | | | | | simplify common usage patterns. llvm-svn: 215407
* R600/SIInstrInfo.cpp: Suppress an warning. [-Wunused-variable]NAKAMURA Takumi2014-08-111-0/+1
| | | | llvm-svn: 215406
* [ARM] Mark VMOVDRR with the RegSequence property and implement the relatedQuentin Colombet2014-08-113-0/+46
| | | | | | | | | | | | | target hook. This patch teaches the compiler that: dX = VMOVDRR rY, rZ is the same as: dX = REG_SEQUENCE rY, ssub_0, rZ, ssub_1 <rdar://problem/12702965> llvm-svn: 215404
OpenPOWER on IntegriCloud