summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-1849-114/+114
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-1749-114/+114
| | | | | | needing to mention the size. llvm-svn: 215868
* Use copy initialization to initialize std::unique_ptr.Rafael Espindola2014-08-173-3/+3
| | | | | | Thanks to David Blaikie for the suggestion. llvm-svn: 215867
* ARM: mark missing functions from RTABISaleem Abdulrasool2014-08-171-0/+24
| | | | | | | Simply indicate the functions that are part of the runtime library that we do not setup libcalls for. This is merely for ease of identification. NFC. llvm-svn: 215863
* ARM: improve RTABI 4.2 conformance on LinuxSaleem Abdulrasool2014-08-172-58/+38
| | | | | | | | | | | | | | | | The set of functions defined in the RTABI was separated for no real reason. This brings us closer to proper utilisation of the functions defined by the RTABI. It also sets the ground for correctly emitting function calls to AEABI functions on all AEABI conforming platforms. The previously existing lie on the behaviour of __ldivmod and __uldivmod is propagated as it is beyond the scope of the change. The changes to the test are due to the fact that we now use the divmod functions which return both the quotient and remainder and thus we no longer need to invoke two functions on Linux (making it closer to EABI's behaviour). llvm-svn: 215862
* ARM: whitespaceSaleem Abdulrasool2014-08-171-5/+5
| | | | | | Whitespace fix, NFC. llvm-svn: 215861
* Remove unused member variable.Rafael Espindola2014-08-171-10/+7
| | | | llvm-svn: 215860
* Return a std::uinque_ptr. Every caller was already using one.Rafael Espindola2014-08-172-5/+6
| | | | llvm-svn: 215858
* Convert an ownership comment with std::uinque_ptr.Rafael Espindola2014-08-173-20/+13
| | | | llvm-svn: 215855
* Pass a std::uinque_ptr to ParseAssembly to make the ownership explicit. NFC.Rafael Espindola2014-08-173-20/+18
| | | | llvm-svn: 215852
* getLazyIRModule always takes ownership. Make that explicit.Rafael Espindola2014-08-171-10/+9
| | | | llvm-svn: 215851
* Return a std::unique_ptr to make the ownership explicit.Rafael Espindola2014-08-171-3/+3
| | | | llvm-svn: 215850
* Don't repeat the function name in comments. NFC.Rafael Espindola2014-08-171-19/+17
| | | | llvm-svn: 215849
* Don't repeat names in comments. NFC.Rafael Espindola2014-08-171-13/+13
| | | | llvm-svn: 215848
* Revert: r215698 - Current implementation of c.cond.fmt instructions only ↵Daniel Sanders2014-08-1714-234/+197
| | | | | | | | | | | accept default cc0 register... It causes a number of regressions when -fintegrated-as is enabled. This happens because there are codegen-only instructions that incorrectly uses the first operand as the encoding for the $fcc register. The regressions do not occur when -via-file-asm is also given. llvm-svn: 215847
* ARM: correct toggling behaviourSaleem Abdulrasool2014-08-172-8/+14
| | | | | | | | | | This was a thinko. The intent was to flip the explicit bits that need toggling rather than all bits. This would result in incorrect behaviour (which now is tested). Thanks to Nico Weber for pointing this out! llvm-svn: 215846
* llvm-objdump: don't print relocations in non-relocatable files.Rafael Espindola2014-08-178-0/+31
| | | | | | This matches the behavior of GNU objdump. llvm-svn: 215844
* Remove a redundant "public:". NFC.Rafael Espindola2014-08-171-1/+0
| | | | llvm-svn: 215842
* BumpPtrAllocator: remove 'no slabs allocated yet' checkHans Wennborg2014-08-172-4/+1
| | | | | | | | | | We already handle the no-slabs case when checking whether the current slab is large enough: if no slabs have been allocated, CurPtr and End are both 0. alignPtr(0), will still be 0, and so "if (Ptr + Size <= End)" fails. Differential Revision: http://reviews.llvm.org/D4943 llvm-svn: 215841
* Add a non-templated ELFObjectFileBase class.Rafael Espindola2014-08-172-63/+42
| | | | | | | Use it to implement some ELF only virtual interfaces instead of using error prone series of dyn_casts. llvm-svn: 215838
* Fix an off-by-one bug in the target independent llvm-objdump.Rafael Espindola2014-08-173-10/+15
| | | | | | | | It would prevent the display of a single byte instruction before a label. Patch by Steve King! llvm-svn: 215837
* Reverted last commitElena Demikhovsky2014-08-171-47/+442
| | | | llvm-svn: 215828
* Reverted last commitElena Demikhovsky2014-08-171-235/+0
| | | | llvm-svn: 215827
* Added a table for intrinsics on X86. Elena Demikhovsky2014-08-172-442/+282
| | | | | | | It should remove dosens of lines in handling instrinsics (in a huge switch) and give an easy way to add new intrinsics. I did not completed to move al intrnsics to the table, I'll do this in the upcomming commits. llvm-svn: 215826
* Remove an InstCombine that transformed patterns like (x * uitofp i1 y) to ↵Owen Anderson2014-08-172-132/+0
| | | | | | | | | | | | | (select y, x, 0.0) when the multiply has fast math flags set. While this might seem like an obvious canonicalization, there is one subtle problem with it. The result of the original expression is undef when x is NaN (remember, fast math flags), but the result of the select is always defined when x is NaN. This means that the new expression is strictly more defined than the original one. One unfortunate consequence of this is that the transform is not reversible! It's always legal to make increase the defined-ness of an expression, but it's not legal to reduce it. Thus, targets that prefer the original form of the expression cannot reverse the transform to recover it. Another way to think of it is that the transform has lost source-level information (the fast math flags), which is undesirable. llvm-svn: 215825
* [x86] Fix an indentation goof in a prior commit. Should have re-runChandler Carruth2014-08-171-2/+2
| | | | | | clang-format. llvm-svn: 215824
* [shuffle] Teach the shufflevector fuzzer to support fixed element types.Chandler Carruth2014-08-171-6/+12
| | | | | | | I'm using this to try to find more minimal test cases by re-fuzzing within a specific domain once errors are found. llvm-svn: 215823
* llvm/test/CodeGen/X86/fmul-combines.ll: Appease Windows x64. <4 x float> is ↵NAKAMURA Takumi2014-08-161-1/+1
| | | | | | passed by stack. llvm-svn: 215821
* Fix fmul combines with constant splat vectorsMatt Arsenault2014-08-163-13/+129
| | | | | | Fixes things like fmul x, 2 -> fadd x, x llvm-svn: 215820
* [x86] Teach lots of the new vector shuffle lowering to use UNPCKChandler Carruth2014-08-164-19/+43
| | | | | | | instructions for blend operations at 128 bits. This was a serious hole in our prior blend lowering. llvm-svn: 215819
* InstCombine: Fix a potential bug in 0 - (X sdiv C) -> (X sdiv -C)David Majnemer2014-08-163-1/+26
| | | | | | | | | | | | | | | While *most* (X sdiv 1) operations will get caught by InstSimplify, it is still possible for a sdiv to appear in the worklist which hasn't been simplified yet. This means that it is possible for 0 - (X sdiv 1) to get transformed into (X sdiv -1); dividing by -1 can make the transform produce undef values instead of the proper result. Sorry for the lack of testcase, it's a bit problematic because it relies on the exact order of operations in the worklist. llvm-svn: 215818
* InstCombine: Combine mul with div.David Majnemer2014-08-162-2/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can combne a mul with a div if one of the operands is a multiple of the other: %mul = mul nsw nuw %a, C1 %ret = udiv %mul, C2 => %ret = mul nsw %a, (C1 / C2) This can expose further optimization opportunities if we end up multiplying or dividing by a power of 2. Consider this small example: define i32 @f(i32 %a) { %mul = mul nuw i32 %a, 14 %div = udiv exact i32 %mul, 7 ret i32 %div } which gets CodeGen'd to: imull $14, %edi, %eax imulq $613566757, %rax, %rcx shrq $32, %rcx subl %ecx, %eax shrl %eax addl %ecx, %eax shrl $2, %eax retq We can now transform this into: define i32 @f(i32 %a) { %shl = shl nuw i32 %a, 1 ret i32 %shl } which gets CodeGen'd to: leal (%rdi,%rdi), %eax retq This fixes PR20681. llvm-svn: 215815
* arm asm: Let .fpu enable instructions, PR20447.Nico Weber2014-08-162-0/+52
| | | | | | | | | I'm not very happy with duplicating the fpu->feature mapping in ARMAsmParser.cpp and in clang's driver. See the bug for a patch that doesn't do that, and the review thread [1] for why this duplication exists. 1: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/231052.html llvm-svn: 215811
* [LIT] Move display of unsupported and xfail tests to summary. Eric Fiselier2014-08-161-4/+7
| | | | | | | | | | | | | | | | | | | | Summary: This patch changes the way xfail and unsupported tests are displayed. This output is only displayed when the --show-unsupported/--show-xfail flags are passed to lit. Currently xfail/unsupported tests are printed during the run of the test-suite. I think its better to display this information during the summary instead. This patch removes the printing of these tests from when they are run to the summary. Reviewers: ddunbar, EricWF Reviewed By: EricWF Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4842 llvm-svn: 215809
* BitcodeReader: Only create one basic block for each blockaddressDuncan P. N. Exon Smith2014-08-163-20/+32
| | | | | | | | | | | | | | | | Block address forward-references are implemented by creating a `BasicBlock` ahead of time that gets inserted in the `Function` when it's eventually encountered. However, if the same blockaddress was used in two separate functions that were parsed *before* the referenced function (and the blockaddress was never used at global scope), two separate basic blocks would get created, one of which would be forgotten creating invalid IR. This commit changes the forward-reference logic to create only one basic block (and always return the same blockaddress). llvm-svn: 215805
* UseListOrder: Correctly count the number of usesDuncan P. N. Exon Smith2014-08-161-2/+2
| | | | | | | | | | This is an off-by-one bug I found by inspection, which would only trigger if the bitcode writer sees more uses of a `Value` than the reader. Since this is only relevant when an instruction gets upgraded somehow, there unfortunately isn't a reasonable way to add test coverage. llvm-svn: 215804
* IR: Don't add inbounds to GEPs of extern_weak variablesDuncan P. N. Exon Smith2014-08-162-3/+16
| | | | | | | | | | | | Global variables that have `extern_weak` linkage may be null, so it's incorrect to add `inbounds` when constant folding. This also fixes a bug when parsing global aliases, whose forward reference placeholders are global variables with `extern_weak` linkage. If GEPs to these aliases are encountered before the alias itself, the GEPs would incorrectly gain the `inbounds` keyword as well. llvm-svn: 215803
* [DAGCombiner] Improve the folding of target independet shuffles to Undef.Andrea Di Biagio2014-08-162-0/+207
| | | | | | | | | | | | | | | | | | | | | | | | | When combining a pair of shuffle nodes, check if the combined shuffle mask is trivially Undef. In case, immediately fold that pair of shuffles to Undef. The lack of checks for undef masks was the root-cause of a poor-codegen bug in the dag combiner. Example: %1 = shufflevector <4 x i32> %A, <4 x i32> %B, <4 x i32> <i32 4, i32 1, i32 1, i32 6> %2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 0, i32 4, i32 1, i32 6> %3 = shufflevector <4 x i32> %2, <4 x i32> undef, <4 x i32> <i32 1, i32 5, i32 3, i32 3> Before this patch, on x86 (with -mcpu=corei7) we failed to fold the entire sequence to Undef value and therefore we generated: shufps $-123, %xmm1, $xmm0 pshufd $-46, %xmm0, %xmm0 With this patch, the entire shuffle sequence is folded to Undef and no shuffles are generated in the output assembly. Added new test cases to test 'combine-vec-shuffle-5.ll'. llvm-svn: 215797
* [PowerPC] Mark fixed-offset byvals as pointed-to by IR valuesHal Finkel2014-08-162-2/+32
| | | | | | | | | | | | A byval object, even if allocated at a fixed offset (prescribed by the ABI) is pointed to by IR values. Most fixed-offset stack objects are not pointed-to by IR values, so the default is to assume this is not possible. However, we need to override the default in this case (instruction scheduling can cause miscompiles otherwise). Fixes PR20280. llvm-svn: 215795
* Make isAliased property for fixed-offset stack objects adjustableHal Finkel2014-08-163-16/+29
| | | | | | | | | | | | | | | | | | | | We used to assume that any fixed-offset stack object was not aliased. This meant that no IR value could point to the memory contained in such an object. This is a reasonable default, but is not a universally-correct target-independent fact. For example, on PowerPC (both Darwin and non-Darwin), some byval arguments are allocated at fixed offsets by the ABI. These, however, certainly can be pointed to by IR values. This change moves the 'isAliased' logic out of FixedStackPseudoSourceValue and into MFI, and allows the isAliased property to be overridden for fixed-offset objects. This will be used by an upcoming commit to the PowerPC backend to fix PR20280. No functionality change intended (the behavior of FixedStackPseudoSourceValue::isAliased has been made more conservative for callers that don't pass an MFI object, but I don't see any in-tree callers that do that). llvm-svn: 215794
* [PowerPC] Darwin byval arguments are not immutableHal Finkel2014-08-161-1/+1
| | | | | | | | | | | | On PPC/Darwin, byval arguments occur at fixed stack offsets in the callee's frame, but are not immutable -- the pointer value is directly available to the higher-level code as the address of the argument, and the value of the byval argument can be modified at the IR level. This is necessary, but not sufficient, to fix PR20280. When PR20280 is fixed in a follow-up commit, its test case will cover this change. llvm-svn: 215793
* Revert "[Support] Promote cl::StringSaver to a separate utility"Sean Silva2014-08-154-43/+45
| | | | | | | | | This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa. LLD has 3 StringSaver's, one of which takes a lock when saving the string... Need to investigate more closely. llvm-svn: 215790
* Get rid of dead code: SelectAtomic64 in X86ISelDAGtoDAG.cppRobin Morisset2014-08-151-19/+0
| | | | llvm-svn: 215789
* [Support] Promote cl::StringSaver to a separate utilitySean Silva2014-08-154-45/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This class is generally useful. In breaking it out, the primary change is that it has been made non-virtual. It seems like being abstract led to there being 3 different (2 in llvm + 1 in clang) concrete implementations which disagreed about the ownership of the saved strings (see the manual call to free() in the unittest StrDupSaver; yes this is different from the CommandLine.cpp StrDupSaver which owns the stored strings; which is different from Clang's StringSetSaver which just holds a reference to a std::set<std::string> which owns the strings). I've identified 2 other places in the codebase that are open-coding this pattern: memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1) I'll be switching them over. They are * llvm::sys::Process::GetArgumentVector * The StringAllocator member of YAMLIO's Input class This also will allow simplifying Clang's driver.cpp quite a bit. Let me know if there are any other places that could benefit from StringSaver. I'm also thinking of adding a saveStringRef member for getting a stable StringRef. llvm-svn: 215784
* Add two helper functions: isAtLeastAcquire, isAtLeastReleaseRobin Morisset2014-08-151-0/+16
| | | | | | | These methods are available on AtomicOrdering values, and will be used in a later separate patch. llvm-svn: 215779
* Fix typos in commentsRobin Morisset2014-08-156-8/+8
| | | | llvm-svn: 215777
* [AArch32] Add support for FP rounding operations for ARMv8/AArch32.Chad Rosier2014-08-153-12/+139
| | | | | | Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
* [Option] Support MultiArg in --helpNick Kledzik2014-08-151-1/+12
| | | | | | | | Currently, if you use a MultiArg<> option, then printing out the help/usage message will cause an assert. This fixes getOptionHelpName() to work with MultiArg Options. llvm-svn: 215770
* Set comdats when lazily linking functions.Rafael Espindola2014-08-153-0/+17
| | | | | | | We were setting the comdat when functions were copied in the initial pass, but not when they were linked only when we found out that they are needed. llvm-svn: 215765
* [FastISel][AArch64] Fix a latent bug in floating-point materialization.Juergen Ributzka2014-08-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | The floating-point value positive zero (+0.0) is a valid immedate value according to isFPImmLegal. As a result AArch64 FastISel went ahead and used the immediate version of fmov to materialize the constant. The problem is that the immediate version of fmov cannot encode an imediate for postive zero. Instead a fmov from the zero register was supposed to be used in this case. This fix adds handling for this special case and uses fmov from the zero register to materialize a positive zero (negative zeroes go to the constant pool). There is no test case for this, because this code is currently dead. It will be enabled in a future commit and I will add a test case in a separate commit after that. This fixes <rdar://problem/18027157>. llvm-svn: 215753
OpenPOWER on IntegriCloud