summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Run clang-format on the parts of AsmPrinterDwarf where it improves theAdrian Prantl2015-01-121-12/+10
| | | | | | readability. llvm-svn: 225726
* Debug Info: Add a virtual destructor to DwarfExpression.Adrian Prantl2015-01-121-0/+1
| | | | | | Thanks Chandler for noticing! llvm-svn: 225724
* [PM] Sink the reference vs. value decision for IR units out of theChandler Carruth2015-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | templated interface. So far, every single IR unit I can come up with has address-identity. That is, when two units of IR are both active in LLVM, their addresses will be distinct of the IR is distinct. This is clearly true for Modules, Functions, BasicBlocks, and Instructions. It turns out that the only practical way to make the CGSCC stuff work the way we want is to make it true for SCCs as well. I expect this pattern to continue. When first designing the pass manager code, I kept this dimension of freedom in the type parameters, essentially allowing for a wrapper-type whose address did not form identity. But that really no longer makes sense and is making the code more complex or subtle for no gain. If we ever have an actual use case for this, we can figure out what makes sense then and there. It will be better because then we will have the actual example in hand. While the simplifications afforded in this patch are fairly small (mostly sinking the '&' out of many type parameters onto a few interfaces), it would have become much more pronounced with subsequent changes. I have a sequence of changes that will completely remove the code duplication that currently exists between all of the pass managers and analysis managers. =] Should make things much cleaner and avoid bug fixing N times for the N pass managers. llvm-svn: 225723
* Untwine this expression. Thanks to David for noticing!Adrian Prantl2015-01-121-1/+1
| | | | llvm-svn: 225720
* [X86][SSE] Minor regression fix for r225551Simon Pilgrim2015-01-121-1/+2
| | | | | | r225551 vector byte shuffle optimization caused an assertion as fully zeroable vectors can be produced under certain circumstances. This fix drops the assert and returns a zero vector where the assert would have failed. llvm-svn: 225718
* Debug Info: Implement DwarfUnit::addRegisterOpPiece() using DwarfExpression.Adrian Prantl2015-01-122-57/+4
| | | | | | NFC. llvm-svn: 225717
* Bitcode: Range-based for, NFCDuncan P. N. Exon Smith2015-01-121-2/+2
| | | | llvm-svn: 225716
* Bitcode: Add abbreviation for METADATA_NAMEDuncan P. N. Exon Smith2015-01-121-3/+12
| | | | llvm-svn: 225715
* Bitcode: Range-based for, NFCDuncan P. N. Exon Smith2015-01-121-7/+4
| | | | llvm-svn: 225714
* Bitcode: Range-based for, NFCDuncan P. N. Exon Smith2015-01-121-4/+4
| | | | llvm-svn: 225713
* Bitcode: Simplify emission of METADATA_BLOCKDuncan P. N. Exon Smith2015-01-123-36/+32
| | | | | | | | | | Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
* AsmParser: Use subclass API instead of MDNode wrappers, NFCDuncan P. N. Exon Smith2015-01-121-4/+4
| | | | | | | | Use subclass API instead of the wrappers in `MDNode` in the assembly parser. This will make the code easier to follow once we have multiple subclasses. llvm-svn: 225711
* AsmParser: Factor duplicated code into ParseMDNode(), NFCDuncan P. N. Exon Smith2015-01-122-27/+24
| | | | llvm-svn: 225710
* AsmParser: Reorder ParseMetadata() logic, NFCDuncan P. N. Exon Smith2015-01-121-13/+13
| | | | llvm-svn: 225709
* AsmParser: Simplify ParseMDTuple(), NFCDuncan P. N. Exon Smith2015-01-121-4/+1
| | | | llvm-svn: 225708
* Debug Info: Implement DwarfUnit::addRegisterOffset using DwarfExpression.Adrian Prantl2015-01-125-16/+60
| | | | | | No functional change. llvm-svn: 225707
* Debug info: Factor out the creation of DWARF expressions from AsmPrinterAdrian Prantl2015-01-124-136/+251
| | | | | | | | | | | | | | into a new class DwarfExpression that can be shared between AsmPrinter and DwarfUnit. This is the first step towards unifying the two entirely redundant implementations of dwarf expression emission in DwarfUnit and AsmPrinter. Almost no functional change — Testcases were updated because asm comments that used to be on two lines now appear on the same line, which is actually preferable. llvm-svn: 225706
* AsmParser: ParseMDNode() => ParseMDTuple(), NFCDuncan P. N. Exon Smith2015-01-122-5/+5
| | | | | | This isn't parsing arbitrary subclasses of `MDNode`, just `MDTuple`. llvm-svn: 225702
* 80-cols; NFCSanjay Patel2015-01-121-13/+13
| | | | llvm-svn: 225700
* AsmParser: Remove unused version of ParseMDNodeID()Duncan P. N. Exon Smith2015-01-122-18/+6
| | | | | | | Merge the two versions of `ParseMDNodeID()` now that no one needs special forward references. llvm-svn: 225699
* AsmParser: Use normal references for metadata attachments, NFCDuncan P. N. Exon Smith2015-01-122-39/+6
| | | | | | | | Remove special parsing logic for metadata attachments. Now that `DebugLoc` is stored normally (since the metadata/value split), we don't need this special forward referencing logic. llvm-svn: 225698
* IR: Prepare for a new UniquableMDNode subclass, NFCDuncan P. N. Exon Smith2015-01-122-12/+57
| | | | | | | | Add generic dispatch for the parts of `UniquableMDNode` that cast to `MDTuple`. This makes adding other subclasses (like PR21433's `MDLocation`) easier. llvm-svn: 225697
* IR: Stop erasing MDNodes from uniquing sets during teardownDuncan P. N. Exon Smith2015-01-122-22/+8
| | | | | | | | | | Stop erasing `MDNode`s from the uniquing sets in `LLVMContextImpl` during teardown (in particular, during `UniquableMDNode::~UniquableMDNode()`). Although it's currently feasible, there isn't any clear benefit and it may not be feasible for other subclasses (which don't explicitly store the lookup hash). llvm-svn: 225696
* [X86] Also create+widen FMIN/FMAX nodes for v2f32.Ahmed Bougacha2015-01-121-1/+18
| | | | | | | | | | | | | | | | This happens in the HINT benchmark, where the SLP-vectorizer created v2f32 fcmp/select code. The "correct" solution would have been to teach the vectorizer cost model that v2f32 isn't legal (because really, it isn't), but if we can vectorize we might as well do so. We legalize these v2f32 FMIN/FMAX nodes by widening to v4f32 later on. v3f32 were already widened to v4f32 by the generic unroll-and-build-vector legalization. rdar://15763436 Differential Revision: http://reviews.llvm.org/D6557 llvm-svn: 225691
* IR: Move creation logic to MDNodeFwdDecl, NFCDuncan P. N. Exon Smith2015-01-121-6/+2
| | | | | | | Same as with `MDTuple`, factor out a `friend MDNode` by moving creation logic to the concrete subclass. llvm-svn: 225690
* IR: Move creation logic down to MDTuple, NFCDuncan P. N. Exon Smith2015-01-121-6/+6
| | | | | | | | | Move creation logic for `MDTuple`s down where it belongs. Once there are a few more subclasses, these functions really won't make much sense here (the `friend` relationship was already awkward). For now, leave the `MDNode` versions around, but have it forward down. llvm-svn: 225685
* IR: Push storeDistinctInContext() down to UniquableMDNode, NFCDuncan P. N. Exon Smith2015-01-121-1/+1
| | | | llvm-svn: 225683
* IR: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-128-70/+74
| | | | | | | | | | | | | | | | | | | | | | | | | Split `GenericMDNode` into two classes (with more descriptive names). - `UniquableMDNode` will be a common subclass for `MDNode`s that are sometimes uniqued like constants, and sometimes 'distinct'. This class gets the (short-lived) RAUW support and related API. - `MDTuple` is the basic tuple that has always been returned by `MDNode::get()`. This is as opposed to more specific nodes to be added soon, which have additional fields, custom assembly syntax, and extra semantics. This class gets the hash-related logic, since other sublcasses of `UniquableMDNode` may need to hash based on other fields. To keep this diff from getting too big, I've added casts to `MDTuple` that won't really scale as new subclasses of `UniquableMDNode` are added, but I'll clean those up incrementally. (No functionality change intended.) llvm-svn: 225682
* IR: Invert logic to simplify control flow, NFCDuncan P. N. Exon Smith2015-01-121-8/+5
| | | | llvm-svn: 225670
* IR: Separate out decrementUnresolvedOperandCount(), NFCDuncan P. N. Exon Smith2015-01-121-6/+8
| | | | llvm-svn: 225667
* IR: Prevent handleChangedOperand() recursionDuncan P. N. Exon Smith2015-01-121-8/+6
| | | | | | | | | | | Instead of returning early on `handleChangedOperand()` recursion (finally identified (and test added) in r225657), prevent it upfront by releasing operands before RAUW. Aside from massively different program flow, there should be no functionality change ;). llvm-svn: 225665
* R600/SI: Use RegisterOperands to specify which operands can accept immediatesTom Stellard2015-01-1210-76/+68
| | | | | | | | | | | | There are some operands which can take either immediates or registers and we were previously using different register class to distinguish between operands that could take immediates and those that could not. This patch switches to using RegisterOperands which should simplify the backend by reducing the number of register classes and also make it easier to implement the assembler. llvm-svn: 225662
* GVN: propagate equalities for floating point comparesSanjay Patel2015-01-121-1/+6
| | | | | | | | | | | | Allow optimizations based on FP comparison values in the same way as integers. This resolves PR17713: http://llvm.org/bugs/show_bug.cgi?id=17713 Differential Revision: http://reviews.llvm.org/D6911 llvm-svn: 225660
* IR: Add test for handleChangedOperand() recursionDuncan P. N. Exon Smith2015-01-121-2/+0
| | | | | | | Turns out this can happen. Remove the `FIXME` and add a testcase that crashes without the extra logic. llvm-svn: 225657
* IR: Separate out recalculateHash(), NFCDuncan P. N. Exon Smith2015-01-121-11/+13
| | | | llvm-svn: 225655
* IR: Separate out helper: resolveAfterOperandChange(), NFCDuncan P. N. Exon Smith2015-01-121-15/+18
| | | | llvm-svn: 225654
* IR: Use SubclassData32 directly, NFCDuncan P. N. Exon Smith2015-01-121-8/+11
| | | | | | | Simplify some logic by accessing `SubclassData32` directly instead of relying on API. llvm-svn: 225653
* RegisterCoalescer: Turn some impossible conditions into assertsMatthias Braun2015-01-121-17/+11
| | | | | | | | This is a fixed version of reverted r225500. It fixes the too early if() continue; of the last patch and adds a comment to the unorthodox loop. llvm-svn: 225652
* IR: Don't allow operands to become unresolvedDuncan P. N. Exon Smith2015-01-121-6/+10
| | | | | | | Operands shouldn't change from being resolved to unresolved during graph construction. Simplify the logic based on that assumption. llvm-svn: 225649
* IR: Remove redundant comment, NFCDuncan P. N. Exon Smith2015-01-121-1/+0
| | | | llvm-svn: 225648
* IR: Simplify code, NFCDuncan P. N. Exon Smith2015-01-121-1/+1
| | | | llvm-svn: 225647
* Add r224985 back with two fixes.Rafael Espindola2015-01-1212-228/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One is that AArch64 has additional restrictions on when local relocations can be used. We have to take those into consideration when deciding to put a L symbol in the symbol table or not. The other is that ld64 requires the relocations to cstring to use linker visible symbols on AArch64. Thanks to Michael Zolotukhin for testing this! Remove doesSectionRequireSymbols. In an assembly expression like bar: .long L0 + 1 the intended semantics is that bar will contain a pointer one byte past L0. In sections that are merged by content (strings, 4 byte constants, etc), a single position in the section doesn't give the linker enough information. For example, it would not be able to tell a relocation must point to the end of a string, since that would look just like the start of the next. The solution used in ELF to use relocation with symbols if there is a non-zero addend. In MachO before this patch we would just keep all symbols in some sections. This would miss some cases (only cstrings on x86_64 were implemented) and was inefficient since most relocations have an addend of 0 and can be represented without the symbol. This patch implements the non-zero addend logic for MachO too. llvm-svn: 225644
* IR: Simplify replaceOperandWith(), NFCDuncan P. N. Exon Smith2015-01-121-4/+3
| | | | | | | | This will call `handleChangedOperand()` less frequently, but in that case (i.e., `isStoredDistinctInContext()`) it has identical logic to here. llvm-svn: 225643
* IR: Remove redundant calls to MDNode::setHash(), NFCDuncan P. N. Exon Smith2015-01-121-2/+0
| | | | | | `storeDistinctInContext()` already calls `setHash(0)`. llvm-svn: 225642
* [ASan] Move the shadow on Windows 32-bit from 0x20000000 to 0x40000000Timur Iskhodzhanov2015-01-121-0/+4
| | | | llvm-svn: 225641
* [SimplifyLibCalls] Factor out fortified libcall handling.Ahmed Bougacha2015-01-123-369/+201
| | | | | | | | This lets us remove CGP duplicate. Differential Revision: http://reviews.llvm.org/D6541 llvm-svn: 225640
* [SimplifyLibCalls] Factor out str/mem libcall optimizations.Ahmed Bougacha2015-01-121-42/+64
| | | | | | | | | Put them in a separate function, so we can reuse them to further simplify fortified libcalls as well. Differential Revision: http://reviews.llvm.org/D6540 llvm-svn: 225639
* [SimplifyLibCalls] Factor out signature checks for fortifiable libcalls.Ahmed Bougacha2015-01-121-27/+73
| | | | | | | | | The checks are the same for fortified counterparts to the libcalls, so we might as well do them in a single place. Differential Revision: http://reviews.llvm.org/D6539 llvm-svn: 225638
* [mips][microMIPS] Implement BEQZ16 and BNEZ16 instructionsJozef Kolek2015-01-1210-0/+107
| | | | | | Differential Revision: http://reviews.llvm.org/D5271 llvm-svn: 225627
* [PowerPC] Fix calls to non-function objectsHal Finkel2015-01-121-5/+22
| | | | | | | | | | | | | | | | | | Looking at r225438 inspired me to see how the PowerPC backend handled the situation (calling a bitcasted TLS global), and it turns out we also produced an error (cannot select ...). What it means to "call" something that is not a function is implementation and platform specific, but in the name of doing something (besides crashing), this makes sure we do what GCC does (treat all such calls as calls through a function pointer -- meaning that the pointer is assumed, as is the convention on PPC, to point to a function descriptor structure holding the actual code address along with the function's TOC pointer and environment pointer). As GCC does, we now do the same for calling regular (non-TLS) non-function globals too. I'm not sure whether this is the most useful way to define the behavior, but at least we won't be alone. llvm-svn: 225617
OpenPOWER on IntegriCloud