summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-062-49/+30
| | | | | | | | DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
* ConstantFold: Don't optimize comparisons with weak linkage objectsDavid Majnemer2014-12-061-1/+4
| | | | | | | | | | | | Consider: void f() {} void __attribute__((weak)) g() {} bool b = &f != &g; It's possble for g to resolve to f if --defsym=g=f is passed on to the linker. llvm-svn: 223585
* I didn't intend to commit this change.David Majnemer2014-12-061-1/+1
| | | | llvm-svn: 223584
* InstSimplify: Optimize away useless unsigned comparisonsDavid Majnemer2014-12-061-1/+1
| | | | | | Code like X < Y && Y == 0 should always be folded away to false. llvm-svn: 223583
* Reformat.NAKAMURA Takumi2014-12-062-29/+21
| | | | llvm-svn: 223580
* IR: Disallow function-local metadata attachmentsDuncan P. N. Exon Smith2014-12-061-0/+2
| | | | | | | | Metadata attachments to instructions cannot be function-local. This is part of PR21532. llvm-svn: 223574
* IR: Disallow complicated function-local metadataDuncan P. N. Exon Smith2014-12-061-48/+27
| | | | | | | | | | Disallow complex types of function-local metadata. The only valid function-local metadata is an `MDNode` whose sole argument is a non-metadata function-local value. Part of PR21532. llvm-svn: 223564
* Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-062-24/+56
| | | | | | | | | DenseMaps." Somehow made DenseMap probe on forever on 32 bit machines. This reverts commit r223478. llvm-svn: 223546
* Fix a bug when pretty-printing DW_OP_deref.Adrian Prantl2014-12-051-0/+3
| | | | llvm-svn: 223493
* LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps.Benjamin Kramer2014-12-052-56/+24
| | | | | | | | Required some APInt massaging to get proper empty/tombstone values. Apart from making the code a bit simpler this also reduces the bucket size of the ConstantInt map from 32 to 24 bytes. llvm-svn: 223478
* IR: Stop relying on GetStringMapEntryFromValue()Duncan P. N. Exon Smith2014-12-051-1/+3
| | | | | | It relies on undefined behaviour. llvm-svn: 223438
* Fix a typo: use of cast where dyn_cast was intendedPhilip Reames2014-12-041-1/+1
| | | | | | | | This bug has the effect of converting a test of isGCRelocate(InvokeInst*) from a false return to a crash. This may be the root cause of the crash Joerg reported against r223137, but I'm still waiting for a clean build of clang to complete to be able to confirm. Once I've confirmed the issue, I'll submit a test case separately. llvm-svn: 223370
* Masked Load / Store Intrinsics - the CodeGen part.Elena Demikhovsky2014-12-043-2/+55
| | | | | | | | | | | | | | | | | | I'm recommiting the codegen part of the patch. The vectorizer part will be send to review again. Masked Vector Load and Store Intrinsics. Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores. Added SDNodes for masked operations and lowering patterns for X86 code generator. Examples: <16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask) declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask) Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch. http://reviews.llvm.org/D6191 llvm-svn: 223348
* A few more checks for gc.statepoints in the VerifierPhilip Reames2014-12-041-0/+11
| | | | | | | | | This is simply a grab bag of unrelated checks: - A statepoint call can't be marked readonly or readnone - We don't currently support inline asm or varadic target functions. Both could be supported, but don't currently work. - I forgot to check that the number of call arguments actually matched the wrapped callee in my previous change. Included here. llvm-svn: 223322
* Strength Verifier checks around the types involved in a statepointPhilip Reames2014-12-031-6/+23
| | | | | | Add checks that the types in a gc.statepoint sequence match the wrapper callee and that relocating a pointer doesn't change it's type. llvm-svn: 223275
* Make the Verifier more strict about gc.statepointsPhilip Reames2014-12-031-28/+60
| | | | | | The recently added documentation for statepoints claimed that we checked the parameters of the various intrinsics for validity. This patch adds the code to actually do so. I also removed a couple of redundant checks for conditions which are checked elsewhere in the Verifier and simplified the logic using the helper functions from Statepoint.h. llvm-svn: 223259
* Ask the module for its the identified types.Rafael Espindola2014-12-031-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When lazy reading a module, the types used in a function will not be visible to a TypeFinder until the body is read. This patch fixes that by asking the module for its identified struct types. If a materializer is present, the module asks it. If not, it uses a TypeFinder. This fixes pr21374. I will be the first to say that this is ugly, but it was the best I could find. Some of the options I looked at: * Asking the LLVMContext. This could be made to work for gold, but not currently for ld64. ld64 will load multiple modules into a single context before merging them. This causes us to see types from future merges. Unfortunately, MappedTypes is not just a cache when it comes to opaque types. Once the mapping has been made, we have to remember it for as long as the key may be used. This would mean moving MappedTypes to the Linker class and having to drop the Linker::LinkModules static methods, which are visible from C. * Adding an option to ignore function bodies in the TypeFinder. This would fix the PR by picking the worst result. It would work, but unfortunately we are currently quite dependent on the upfront type merging. I will try to reduce our dependency, but it is not clear that we will be able to get rid of it for now. The only clean solution I could think of is making the Module own the types. This would have other advantages, but it is a much bigger change. I will propose it, but it is nice to have this fixed while that is discussed. With the gold plugin, this patch takes the number of types in the LTO clang binary from 52817 to 49669. llvm-svn: 223215
* Prologue supportPeter Collingbourne2014-12-034-4/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
* [Statepoints 3/4] Statepoint infrastructure for garbage collection: ↵Philip Reames2014-12-022-0/+63
| | | | | | | | | | | | | | | | | | SelectionDAGBuilder This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them. With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now. I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it. During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases. In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure. Reviewed by: atrick, ributzka llvm-svn: 223137
* [Statepoints 1/4] Statepoint infrastructure for garbage collection: IR ↵Philip Reames2014-12-011-0/+81
| | | | | | | | | | | | | | Intrinsics The statepoint intrinsics are intended to enable precise root tracking through the compiler as to support garbage collectors of all types. The addition of the statepoint intrinsics to LLVM should have no impact on the compilation of any program which does not contain them. There are no side tables created, no extra metadata, and no inhibited optimizations. A statepoint works by transforming a call site (or safepoint poll site) into an explicit relocation operation. It is the frontend's responsibility (or eventually the safepoint insertion pass we've developed, but that's not part of this patch series) to ensure that any live pointer to a GC object is correctly added to the statepoint and explicitly relocated. The relocated value is just a normal SSA value (as seen by the optimizer), so merges of relocated and unrelocated values are just normal phis. The explicit relocation operation, the fact the statepoint is assumed to clobber all memory, and the optimizers standard semantics ensure that the relocations flow through IR optimizations correctly. This is the first patch in a small series. This patch contains only the IR parts; the documentation and backend support will be following separately. The entire series can be seen as one combined whole in http://reviews.llvm.org/D5683. Reviewed by: atrick, ributzka llvm-svn: 223078
* Parse 'ghccc' in .ll files as the GHC convention (cc 10)Reid Kleckner2014-12-011-0/+1
| | | | | | | Previously we just used "cc 10" in the .ll files, but that isn't very human readable. llvm-svn: 223076
* Revert "Masked Vector Load and Store Intrinsics."Duncan P. N. Exon Smith2014-11-283-55/+2
| | | | | | | | | | | This reverts commit r222632 (and follow-up r222636), which caused a host of LNT failures on an internal bot. I'll respond to the commit on the list with a reproduction of one of the failures. Conflicts: lib/Target/X86/X86TargetTransformInfo.cpp llvm-svn: 222936
* Revert r220349 to re-instate r220277 with a fix for PR21330 -- quiteChandler Carruth2014-11-251-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | clearly only exactly equal width ptrtoint and inttoptr casts are no-op casts, it says so right there in the langref. Make the code agree. Original log from r220277: Teach the load analysis to allow finding available values which require inttoptr or ptrtoint cast provided there is datalayout available. Eventually, the datalayout can just be required but in practice it will always be there today. To go with the ability to expose available values requiring a ptrtoint or inttoptr cast, helpers are added to perform one of these three casts. These smarts are necessary to finish canonicalizing loads and stores to the operational type requirements without regressing fundamental combines. I've added some test cases. These should actually improve as the load combining and store combining improves, but they may fundamentally be highlighting some missing combines for select in addition to exercising the specific added logic to load analysis. llvm-svn: 222739
* Revert "unique_ptrify LLVMContextImpl::CAZConstants"David Blaikie2014-11-253-9/+6
| | | | | | | | Missed the complexities of how these elements are destroyed. This reverts commit r222714. llvm-svn: 222715
* unique_ptrify LLVMContextImpl::CAZConstantsDavid Blaikie2014-11-253-6/+9
| | | | llvm-svn: 222714
* Incorporate review comments from r221742Philip Reames2014-11-241-2/+11
| | | | | | This change implements the comment and style changes Sean requested during post commit review with r221742. Sorry for the delay. llvm-svn: 222707
* Masked Vector Load and Store Intrinsics.Elena Demikhovsky2014-11-233-2/+55
| | | | | | | | | | | | | | Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores. Added SDNodes for masked operations and lowering patterns for X86 code generator. Examples: <16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask) declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask) Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch. http://reviews.llvm.org/D6191 llvm-svn: 222632
* [InstCombine] Re-commit of r218721 (Optimize icmp-select-icmp sequence)Gerolf Hoflehner2014-11-211-0/+22
| | | | | | | Fixes the self-host fail. Note that this commit activates dominator analysis in the combiner by default (like the original commit did). llvm-svn: 222590
* Debug Info: revert r222195, r222210 and r222239.Manman Ren2014-11-212-4/+4
| | | | | | | This is no longer needed after David's fix at r222377 + r222485. rdar://18958417 llvm-svn: 222563
* Debug Info: add an assertion that the context field of a global variable can notManman Ren2014-11-211-1/+8
| | | | | | | | | | | be a DIType with identifier. This makes sure that there is no need to use DIScopeRef for global variable's context. rdar://18958417 llvm-svn: 222561
* Add params() to FunctionType. NFC.Rafael Espindola2014-11-211-4/+3
| | | | | | While at it, also use makeArrayRef in elements(). llvm-svn: 222556
* Add and use a helper elements() to StructType. NFC.Rafael Espindola2014-11-211-3/+2
| | | | llvm-svn: 222553
* Add curly braces to workaround an MSVC bug.Zachary Turner2014-11-211-1/+3
| | | | | | MSVC can't parse this pattern for range-based for loops. llvm-svn: 222491
* Verifier: Check that all instructions have their parent pointers set upAdrian Prantl2014-11-211-0/+4
| | | | | | | correctly. This helps with catching problems caused by IRBuilder abuse such as the one fixed in CFE r222487. llvm-svn: 222488
* Do not create a replaceable Variables MDNode for function forward decls.Frederic Riss2014-11-201-4/+4
| | | | | | | | These fields would need to be explicitly deleted before we RAUW the temporary node anyway (this was done in cfe commit r222373). Instead, do not create these useless nodes in the first place. llvm-svn: 222434
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-196-20/+20
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* Remove StringMap::GetOrCreateValue in favor of StringMap::insertDavid Blaikie2014-11-195-36/+32
| | | | | | | | | | | | | | Having two ways to do this doesn't seem terribly helpful and consistently using the insert version (which we already has) seems like it'll make the code easier to understand to anyone working with standard data structures. (I also updated many references to the Entry's key and value to use first() and second instead of getKey{Data,Length,} and get/setValue - for similar consistency) Also removes the GetOrCreateValue functions so there's less surface area to StringMap to fix/improve/change/accommodate move semantics, etc. llvm-svn: 222319
* IR: Sink MDNode::Hash down to GenericMDNode::HashDuncan P. N. Exon Smith2014-11-181-1/+1
| | | | | | Part of PR21532. llvm-svn: 222212
* IR: Move MDNode operands from the back to the frontDuncan P. N. Exon Smith2014-11-182-58/+45
| | | | | | | | | | | | | | | | | Having the operands at the back prevents subclasses from safely adding fields. Move them to the front. Instead of replicating the custom `malloc()`, `free()` and `DestroyFlag` logic that was there before, overload `new` and `delete`. I added calls to a new `GenericMDNode::dropAllReferences()` in `LLVMContextImpl::~LLVMContextImpl()`. There's a maze of callbacks happening during teardown, and this resolves them before we enter the destructors. Part of PR21532. llvm-svn: 222211
* IR: Split MDNode into GenericMDNode and MDNodeFwdDeclDuncan P. N. Exon Smith2014-11-183-43/+57
| | | | | | | | | | | | | | | | | | | Split `MDNode` into two classes: - `GenericMDNode`, which is uniquable (and for now, always starts uniqued). Once `Metadata` is split from the `Value` hierarchy, this class will lose the ability to RAUW itself. - `MDNodeFwdDecl`, which is used for the "temporary" interface, is never uniqued, and isn't managed by `LLVMContext` at all. I've left most of the guts in `MDNode` for now, but I'll incrementally move things to the right places (or delete the functionality, as appropriate). Part of PR21532. llvm-svn: 222205
* Debug Info: In DIBuilder, the context field of a global variable is updated toManman Ren2014-11-182-4/+4
| | | | | | | | | | | use DIScopeRef. A paired commit at clang will follow to show cases where we will use an identifer for the context of a global variable. rdar://18958417 llvm-svn: 222195
* IR: Simplify uniquing for MDNodeDuncan P. N. Exon Smith2014-11-173-73/+82
| | | | | | | | | | | | | | | | | | Change uniquing from a `FoldingSet` to a `DenseSet` with custom `DenseMapInfo`. Unfortunately, this doesn't save any memory, since `DenseSet<T>` is a simple wrapper for `DenseMap<T, char>`, but I'll come back to fix that later. I used the name `GenericDenseMapInfo` to the custom `DenseMapInfo` since I'll be splitting `MDNode` into two classes soon: `MDNodeFwdDecl` for temporaries, and `GenericMDNode` for everything else. I also added a non-debug-info reduced version of a type-uniquing test that started failing on an earlier draft of this patch. Part of PR21532. llvm-svn: 222191
* DIBuilder: Use Constant instead of ValueDuncan P. N. Exon Smith2014-11-151-29/+20
| | | | | | | | | Make explicit the requirement that most IR values in `DIBuilder` are `Constant`. This requires a follow-up change in clang. Part of PR21532. llvm-svn: 222070
* DIBuilder: Change private helper function to static, NFCDuncan P. N. Exon Smith2014-11-151-14/+11
| | | | llvm-svn: 222068
* DI: Use Metadata for DITypeRef and DIScopeRefDuncan P. N. Exon Smith2014-11-141-18/+20
| | | | | | | | | | Now that `MDString` and `MDNode` have a common base class, use it. Note that it's not useful to assume subclasses of `Metadata` must be one or the other since we'll be adding more subclasses soon enough. Part of PR21532. llvm-svn: 222064
* IR: Make MDString inherit from MetadataDuncan P. N. Exon Smith2014-11-141-3/+0
| | | | llvm-svn: 222022
* IR: Take an LLVMContext in Metadata::Metadata()Duncan P. N. Exon Smith2014-11-141-1/+4
| | | | llvm-svn: 222019
* Add a blank line, NFCDuncan P. N. Exon Smith2014-11-141-0/+1
| | | | llvm-svn: 222018
* IR: Rewrite uniquing and creation of MDStringDuncan P. N. Exon Smith2014-11-143-9/+17
| | | | | | | | | | Stop using `Value::getName()` to get the string behind an `MDString`. Switch to `StringMapEntry<MDString>` so that we can find the string by its coallocation. This is part of PR21532. llvm-svn: 221960
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-132-5/+5
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
OpenPOWER on IntegriCloud