summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* MC CFG: uint64_t -> size_t for vector size.Ahmed Bougacha2013-08-211-1/+1
| | | | llvm-svn: 188872
* MC CFG: Add a getter for MCDataAtom's data array.Ahmed Bougacha2013-08-211-1/+5
| | | | | | While there, switch to new-style documentation. llvm-svn: 188871
* DebugInfo: Do not use the DWARF Version for the .debug_pubnames or ↵David Majnemer2013-08-213-3/+7
| | | | | | | | | | | | | | | | | | | | | | | .debug_pubtypes version field Summary: LLVM would generate DWARF with version 3 in the .debug_pubname and .debug_pubtypes version fields. This would lead SGI dwarfdump to fail parsing the DWARF with (in the instance of .debug_pubnames) would exit with: dwarfdump ERROR: dwarf_get_globals: DW_DLE_PUBNAMES_VERSION_ERROR (123) This fixes PR16950. Reviewers: echristo, dblaikie Reviewed By: echristo CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1454 llvm-svn: 188869
* Synchronize VEX JIT encoding code with the MCJIT version. Fix a bug in the ↵Craig Topper2013-08-212-12/+11
| | | | | | MCJIT code where CurOp was being incremented even if the operand it was pointing at wasn't used. Maybe only matters if there are any EVEX_K instructions that aren't VEX_4V. llvm-svn: 188868
* In LLVM FMA3 operands are dst, src1, src2, src3, however dst is not encoded ↵Nadav Rotem2013-08-212-2/+26
| | | | | | | | as it is always src1. This was causing the encoding of the operands to be off by one. Patch by Chris Bieneman. llvm-svn: 188866
* Add the FMA3 feature in order to test FMA encoding using the old jit.Nadav Rotem2013-08-211-0/+10
| | | | | | Patch by Chris Bieneman! llvm-svn: 188865
* Rename mattr names for AVX-512 to from avx-512 -> avx512f, avx-512-pfi -> ↵Craig Topper2013-08-213-7/+7
| | | | | | av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening. llvm-svn: 188859
* X86TargetMachine.cpp: Clarify to emit GOT in i686-{cygming|win32}-elf for mcjit.NAKAMURA Takumi2013-08-215-5/+5
| | | | | | I suppose all "lli -use-mcjit i686-*" should require GOT, (and to fail.) llvm-svn: 188856
* lli/RecordingMemoryManager.cpp: Make it complain if _GLOBAL_OFFSET_TABLE_ ↵NAKAMURA Takumi2013-08-211-0/+7
| | | | | | | were not provided. FIXME: Would it be responsible to provide GOT? llvm-svn: 188855
* Move #includes from .h to .cpp file.Jakub Staszak2013-08-212-2/+2
| | | | llvm-svn: 188852
* [micromips] Print instruction alias "not" if the last operand of a nor is zero.Akira Hatanaka2013-08-212-2/+3
| | | | llvm-svn: 188851
* Move registering the execution of a basic block to the beginning rather than ↵Bill Wendling2013-08-201-7/+7
| | | | | | | | | | | | | | | | | the end. There are situations which can affect the correctness (or at least expectation) of the gcov output. For instance, if a call to __gcov_flush() occurs within a block before the execution count is registered and then the program aborts in some way, then that block will not be marked as executed. This is not normally what the user expects. If we move the code that's registering when a block is executed to the beginning, we can catch these types of situations. PR16893 llvm-svn: 188849
* [mips] Add support for mfhc1 and mthc1.Akira Hatanaka2013-08-204-25/+62
| | | | llvm-svn: 188848
* [mips] Add support for calling convention CC_MipsO32_FP64, which is used ↵Akira Hatanaka2013-08-206-32/+70
| | | | | | | | | | when the size of floating point registers is 64-bit. Test case will be added when support for mfhc1 and mthc1 is added. llvm-svn: 188847
* [mips] Remove predicates that were incorrectly or unnecessarily added.Akira Hatanaka2013-08-203-6/+6
| | | | llvm-svn: 188845
* Add some constantness.Jakub Staszak2013-08-203-8/+11
| | | | llvm-svn: 188844
* Use -disable-output and to suppress output and don't use a temporary file ↵Bill Wendling2013-08-205-7/+5
| | | | | | unless we need one. llvm-svn: 188843
* [mips] Define register class FGRH32 for the high half of the 64-bit floatingAkira Hatanaka2013-08-206-16/+60
| | | | | | | | point registers. We will need this register class later when we add definitions for instructions mfhc1 and mthc1. Also, remove sub-register indices sub_fpeven and sub_fpodd and use sub_lo and sub_hi instead. llvm-svn: 188842
* Fix include guards.Jakub Staszak2013-08-202-4/+4
| | | | llvm-svn: 188841
* SLPVectorizer: Fix invalid iterator errorsArnold Schwaighofer2013-08-202-13/+81
| | | | | | | | | | | Update iterator when the SLP vectorizer changes the instructions in the basic block by restarting the traversal of the basic block. Patch by Yi Jiang! Fixes PR 16899. llvm-svn: 188832
* Teach ConstantFolding about pointer address spacesMatt Arsenault2013-08-205-37/+585
| | | | llvm-svn: 188831
* [mips] Resolve register classes dynamically using ptr_rc to reduce the number ofAkira Hatanaka2013-08-2010-371/+184
| | | | | | | | load/store instructions defined. Previously, we were defining load/store instructions for each pointer size (32 and 64-bit), but now we need just one definition. llvm-svn: 188830
* Add an option which permits the user to specify using a bitmask, that variousReed Kotler2013-08-202-6/+51
| | | | | | | | | functions be compiled as mips32, without having to add attributes. This is useful in certain situations where you don't want to have to edit the function attributes in the source. For now it's only an option used for the compiler developers when debugging the mips16 port. llvm-svn: 188826
* [mips] Guard micromips instructions with predicate InMicroMips. Also, fixAkira Hatanaka2013-08-203-14/+12
| | | | | | assembler predicate HasStdEnd so that it is false when the target is micromips. llvm-svn: 188824
* ARM: Fix fast-isel copy/paste-o.Jim Grosbach2013-08-202-6/+7
| | | | | | | | | | | | Update testcase to be more careful about checking register values. While regexes are general goodness for these sorts of testcases, in this example, the registers are constrained by the calling convention, so we can and should check their explicit values. rdar://14779513 llvm-svn: 188819
* Still more MCJIT PIC test XFAILsAndrew Kaylor2013-08-203-3/+3
| | | | llvm-svn: 188815
* Clarifying two MCJIT PIC tests as XFAIL on i686-pc-linuxAndrew Kaylor2013-08-204-4/+4
| | | | llvm-svn: 188814
* Removing duplicate XFAIL markersAndrew Kaylor2013-08-202-2/+2
| | | | llvm-svn: 188812
* Marking two more MCJIT PIC tests as XFAIL on i686Andrew Kaylor2013-08-204-4/+4
| | | | llvm-svn: 188808
* Marking MCJIT PIC tests as XFAIL on armAndrew Kaylor2013-08-206-6/+6
| | | | llvm-svn: 188807
* Fix style issues in AsmParser.cppVladimir Medic2013-08-201-9/+11
| | | | llvm-svn: 188798
* AVX-512: Added more patterns for VMOVSS, VMOVSD, VMOVD, VMOVQElena Demikhovsky2013-08-203-12/+98
| | | | llvm-svn: 188786
* [mips][msa] Removed fcge, fcgt, fsge, fsgtDaniel Sanders2013-08-203-240/+0
| | | | | | | These instructions were present in a draft spec but were removed before publication. llvm-svn: 188782
* [SystemZ] Update READMERichard Sandiford2013-08-201-4/+2
| | | | | | We now use MVST, CLST and SRST for the obvious cases. llvm-svn: 188781
* [SystemZ] Use SRST to optimize memchrRichard Sandiford2013-08-2010-3/+171
| | | | | | | | | | | | | | | | | | | SystemZTargetLowering::emitStringWrapper() previously loaded the character into R0 before the loop and made R0 live on entry. I'd forgotten that allocatable registers weren't allowed to be live across blocks at this stage, and it confused LiveVariables enough to cause a miscompilation of f3 in memchr-02.ll. This patch instead loads R0 in the loop and leaves LICM to hoist it after RA. This is actually what I'd tried originally, but I went for the manual optimisation after noticing that R0 often wasn't being hoisted. This bug forced me to go back and look at why, now fixed as r188774. We should also try to optimize null checks so that they test the CC result of the SRST directly. The select between null and the SRST GPR result could then usually be deleted as dead. llvm-svn: 188779
* memcmp is not a valid way to compare structs with padding in them.Benjamin Kramer2013-08-201-2/+9
| | | | llvm-svn: 188778
* [mips][msa] Added insveDaniel Sanders2013-08-203-0/+140
| | | | llvm-svn: 188777
* Fix test typo and add usual "br %r14" testRichard Sandiford2013-08-201-1/+2
| | | | llvm-svn: 188775
* Fix overly pessimistic shortcut in post-RA MachineLICMRichard Sandiford2013-08-202-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Post-RA LICM keeps three sets of registers: PhysRegDefs, PhysRegClobbers and TermRegs. When it sees a definition of R it adds all aliases of R to the corresponding set, so that when it needs to test for membership it only needs to test a single register, rather than worrying about aliases there too. E.g. the final candidate loop just has: unsigned Def = Candidates[i].Def; if (!PhysRegClobbers.test(Def) && ...) { to test whether register Def is multiply defined. However, there was also a shortcut in ProcessMI to make sure we didn't add candidates if we already knew that they would fail the final test. This shortcut was more pessimistic than the final one because it checked whether _any alias_ of the defined register was multiply defined. This is too conservative for targets that define register pairs. E.g. on z, R0 and R1 are sometimes used as a pair, so there is a 128-bit register that aliases both R0 and R1. If a loop used R0 and R1 independently, and the definition of R0 came first, we would be able to hoist the R0 assignment (because that used the final test quoted above) but not the R1 assignment (because that meant we had two definitions of the paired R0/R1 register and would fail the shortcut in ProcessMI). This patch just uses the same check for the ProcessMI shortcut as we use in the final candidate loop. llvm-svn: 188774
* ARM: implement some simple f64 materializations.Tim Northover2013-08-203-13/+110
| | | | | | | | Previously we used a const-pool load for virtually all 64-bit floating values. Actually, we can get quite a few common values (including 0.0, 1.0) via "vmov" instructions of one stripe or another. llvm-svn: 188773
* [stackprotector] Small cleanup.Michael Gottesman2013-08-201-1/+2
| | | | llvm-svn: 188772
* [stackprotector] Small Bit of computation hoisting.Michael Gottesman2013-08-201-5/+5
| | | | llvm-svn: 188771
* [stackprotector] Added significantly longer comment to FindPotentialTailCall ↵Michael Gottesman2013-08-201-1/+6
| | | | | | to make clear its relationship to llvm::isInTailCallPosition. llvm-svn: 188770
* Removed trailing whitespace.Michael Gottesman2013-08-201-18/+18
| | | | llvm-svn: 188769
* [stackprotector] Removed stale TODO.Michael Gottesman2013-08-201-6/+3
| | | | llvm-svn: 188768
* [mips][msa] Added and.v, bmnz.v, bmz.v, bsel.v, nor.v, or.v, xor.vDaniel Sanders2013-08-204-0/+261
| | | | llvm-svn: 188767
* [stackprotector] Added support for emitting the llvm intrinsic stack ↵Michael Gottesman2013-08-201-49/+150
| | | | | | | | protector check. rdar://13935163 llvm-svn: 188766
* [stackprotector] Refactor out the end of isInTailCallPosition into the ↵Michael Gottesman2013-08-202-1/+17
| | | | | | | | | | function returnTypeIsEligibleForTailCall. This allows me to use returnTypeIsEligibleForTailCall in the stack protector pass. rdar://13935163 llvm-svn: 188765
* Remove unused variables that crept in.Michael Gottesman2013-08-201-6/+0
| | | | llvm-svn: 188761
* Teach selectiondag how to handle the stackprotectorcheck intrinsic.Michael Gottesman2013-08-203-4/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, generation of stack protectors was done exclusively in the pre-SelectionDAG Codegen LLVM IR Pass "Stack Protector". This necessitated splitting basic blocks at the IR level to create the success/failure basic blocks in the tail of the basic block in question. As a result of this, calls that would have qualified for the sibling call optimization were no longer eligible for optimization since said calls were no longer right in the "tail position" (i.e. the immediate predecessor of a ReturnInst instruction). Then it was noticed that since the sibling call optimization causes the callee to reuse the caller's stack, if we could delay the generation of the stack protector check until later in CodeGen after the sibling call decision was made, we get both the tail call optimization and the stack protector check! A few goals in solving this problem were: 1. Preserve the architecture independence of stack protector generation. 2. Preserve the normal IR level stack protector check for platforms like OpenBSD for which we support platform specific stack protector generation. The main problem that guided the present solution is that one can not solve this problem in an architecture independent manner at the IR level only. This is because: 1. The decision on whether or not to perform a sibling call on certain platforms (for instance i386) requires lower level information related to available registers that can not be known at the IR level. 2. Even if the previous point were not true, the decision on whether to perform a tail call is done in LowerCallTo in SelectionDAG which occurs after the Stack Protector Pass. As a result, one would need to put the relevant callinst into the stack protector check success basic block (where the return inst is placed) and then move it back later at SelectionDAG/MI time before the stack protector check if the tail call optimization failed. The MI level option was nixed immediately since it would require platform specific pattern matching. The SelectionDAG level option was nixed because SelectionDAG only processes one IR level basic block at a time implying one could not create a DAG Combine to move the callinst. To get around this problem a few things were realized: 1. While one can not handle multiple IR level basic blocks at the SelectionDAG Level, one can generate multiple machine basic blocks for one IR level basic block. This is how we handle bit tests and switches. 2. At the MI level, tail calls are represented via a special return MIInst called "tcreturn". Thus if we know the basic block in which we wish to insert the stack protector check, we get the correct behavior by always inserting the stack protector check right before the return statement. This is a "magical transformation" since no matter where the stack protector check intrinsic is, we always insert the stack protector check code at the end of the BB. Given the aforementioned constraints, the following solution was devised: 1. On platforms that do not support SelectionDAG stack protector check generation, allow for the normal IR level stack protector check generation to continue. 2. On platforms that do support SelectionDAG stack protector check generation: a. Use the IR level stack protector pass to decide if a stack protector is required/which BB we insert the stack protector check in by reusing the logic already therein. If we wish to generate a stack protector check in a basic block, we place a special IR intrinsic called llvm.stackprotectorcheck right before the BB's returninst or if there is a callinst that could potentially be sibling call optimized, before the call inst. b. Then when a BB with said intrinsic is processed, we codegen the BB normally via SelectBasicBlock. In said process, when we visit the stack protector check, we do not actually emit anything into the BB. Instead, we just initialize the stack protector descriptor class (which involves stashing information/creating the success mbbb and the failure mbb if we have not created one for this function yet) and export the guard variable that we are going to compare. c. After we finish selecting the basic block, in FinishBasicBlock if the StackProtectorDescriptor attached to the SelectionDAGBuilder is initialized, we first find a splice point in the parent basic block before the terminator and then splice the terminator of said basic block into the success basic block. Then we code-gen a new tail for the parent basic block consisting of the two loads, the comparison, and finally two branches to the success/failure basic blocks. We conclude by code-gening the failure basic block if we have not code-gened it already (all stack protector checks we generate in the same function, use the same failure basic block). llvm-svn: 188755
OpenPOWER on IntegriCloud