summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Function.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Add facility to add/remove/check attribute on function and arguments.Amaury Sechet2016-03-141-18/+20
| | | | | | | | | | | | Summary: This comes from work to make attribute manipulable via the C API. Reviewers: gottesmm, hfinkel, baldrick, echristo, tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18128 llvm-svn: 263404
* Remove uses of builtin comma operator.Richard Trieu2016-02-181-4/+10
| | | | | | Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261270
* Refactor PGO function naming and MD5 hashing support out of ProfileDataTeresa Johnson2016-02-091-0/+24
| | | | | | | | | | | | | | | | | | | | Summary: Move the function renaming logic into the Function class, and the MD5Hash routine into the MD5 header. This will enable these routines to be shared with ThinLTO, which will be changed to store the MD5 hash instead of full function name in the combined index for significant size reductions. And using the same function naming for locals in the function index facilitates future integration with indirect call value profiles. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17006 llvm-svn: 260197
* Handle more edge cases in intrinsic name binary searchReid Kleckner2016-01-261-40/+1
| | | | | | | I tried to make the AMDGPU intrinsic info table use this instead of another StringMatcher, and some issues arose. llvm-svn: 258871
* Use binary search for intrinsic ID lookupsReid Kleckner2016-01-261-14/+60
| | | | | | | | This improves compile time of Function.cpp from 57s to 37s for me locally. Intrinsic IDs are cached on the Function object, so this shouldn't regress performance. llvm-svn: 258774
* [opaque pointer types] Remove an unnecessary extra explicit value type in ↵David Blaikie2016-01-151-3/+4
| | | | | | | | Function Now that this is up in GlobalValue, just use the value there. llvm-svn: 257949
* Remove static global GCNames from Function.cpp and move it to the ContextMehdi Amini2016-01-081-35/+9
| | | | | | | | | This remove the need for locking when deleting a function. Differential Revision: http://reviews.llvm.org/D15988 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
* [Function] Properly remove use when clearing personalityKeno Fischer2015-12-231-9/+10
| | | | | | | | | | | | | | | | | Summary: We need to actually remove the use of the personality function, otherwise we can run into trouble if we want to e.g. delete the personality function because ther's no way to get rid of its uses. Do this by resetting to ConstantPointerNull value that the operands are set to when first allocated. Reviewers: vsk, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15752 llvm-svn: 256345
* Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-76/+55
| | | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Does not use binary literals. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256095
* Revert "Reapply "[IR] Move optional data in llvm::Function into a hungoff ↵Vedant Kumar2015-12-191-55/+76
| | | | | | | | | | uselist"" This reverts commit r256093. This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions. llvm-svn: 256094
* Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-76/+55
| | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256093
* Revert "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-54/+76
| | | | | | | | This reverts commit r256090. This broke llvm-clang-lld-x86_64-debian-fast. llvm-svn: 256091
* [IR] Move optional data in llvm::Function into a hungoff uselistVedant Kumar2015-12-191-76/+54
| | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256090
* Don't copy information from aliasee to alias.Rafael Espindola2015-12-021-4/+6
| | | | | | They are independent. llvm-svn: 254541
* Add vector types for intrinsicsKrzysztof Parzyszek2015-11-241-1/+11
| | | | | Author: Ron Lieberman <ronl@codeaurora.org> llvm-svn: 253992
* Pointers in Masked Load, Store, Gather, Scatter intrinsicsElena Demikhovsky2015-11-191-1/+4
| | | | | | | | | | The masked intrinsics support all integer and floating point data types. I added the pointer type to this list. Added tests for CodeGen and for Loop Vectorizer. Updated the Language Reference. Differential Revision: http://reviews.llvm.org/D14150 llvm-svn: 253544
* IR: Remove implicit iterator conversions from lib/IR, NFCDuncan P. N. Exon Smith2015-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
* IR: Create SymbolTableList wrapper around iplist, NFCDuncan P. N. Exon Smith2015-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Create `SymbolTableList`, a wrapper around `iplist` for lists that automatically manage a symbol table. This commit reduces a ton of code duplication between the six traits classes that were used previously. As a drive by, reduce the number of template parameters from 2 to 1 by using a SymbolTableListParentType metafunction (I originally had this as a separate commit, but it touched most of the same lines so I squashed them). I'm in the process of trying to remove the UB in `createSentinel()` (see the FIXMEs I added for `ilist_embedded_sentinel_traits` and `ilist_half_embedded_sentinel_traits`). My eventual goal is to separate the list logic into a base class layer that knows nothing about (and isn't templated on) the downcasted nodes -- removing the need to invoke UB -- but for now I'm just trying to get a handle on all the current use cases (and cleaning things up as I see them). Besides these six SymbolTable lists, there are two others that use the addNode/removeNode/transferNodes() hooks: the `MachineInstruction` and `MachineBasicBlock` lists. Ideally there'll be a way to factor these hooks out of the low-level API entirely, but I'm not quite there yet. llvm-svn: 249602
* [Function] Clean up {prefix,prologue} data routines (NFC)Vedant Kumar2015-10-061-36/+35
| | | | | | | | | | | Factor out some common code used to get+set function prefix/prologue data. This may come in handy if we ever decide to store personality functions in the same way we store prefix/prologue data. Differential Revision: http://reviews.llvm.org/D13120 Reviewed-by: bogner llvm-svn: 249460
* [TableGen] Allow TokenTy in intrinsic signaturesJoseph Tremoulet2015-09-021-16/+21
| | | | | | | | | | | | | | | | | Summary: Add the necessary plumbing so that llvm_token_ty can be used as an argument/return type in intrinsic definitions and correspondingly require TokenTy in function types. TokenTy is an opaque type that has no target lowering, but can be used in machine-independent intrinsics. It is required for the upcoming llvm.eh.padparam intrinsic. Reviewers: majnemer, rnk Subscribers: stoklund, llvm-commits Differential Revision: http://reviews.llvm.org/D12532 llvm-svn: 246651
* [opaque pointer types] Push the passing of value types up from ↵David Blaikie2015-08-211-1/+1
| | | | | | | | | Function/GlobalVariable to GlobalObject (coming next, pushing this up into GlobalValue, so it can store the value type directly) llvm-svn: 245742
* [CallGraph] Teach the CallGraph about non-leaf intrinsics.Sanjoy Das2015-06-181-0/+12
| | | | | | | | | | | | | | | | | | | | Summary: Currently intrinsics don't affect the creation of the call graph. This is not accurate with respect to statepoint and patchpoint intrinsics -- these do call (or invoke) LLVM level functions. This change fixes this inconsistency by adding a call to the external node for call sites that call these non-leaf intrinsics. This coupled with the fact that these intrinsics also escape the function pointer they call gives us a conservatively correct call graph. Reviewers: reames, chandlerc, atrick, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10526 llvm-svn: 240039
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-2/+30
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* ArgumentPromotion: Drop sret attribute on functions that are only called ↵Peter Collingbourne2015-06-101-3/+1
| | | | | | | | | | | | | | | | | | | directly. If the first argument to a function is a 'this' argument and the second has the sret attribute, the ArgumentPromotion pass may promote the 'this' argument to more than one argument, violating the IR constraint that 'sret' may only be applied to the first or second argument. Although this IR constraint is arguably unnecessary, it highlighted the fact that ArgPromotion does not need to preserve this attribute. Dropping the attribute reduces register pressure in the backend by avoiding the register copy required by sret. Because sret implies noalias, we also replace the former with the latter. Differential Revision: http://reviews.llvm.org/D10353 llvm-svn: 239488
* This patch adds support for the vector quadword add/sub instructions introducedKit Barton2015-05-251-1/+5
| | | | | | | | | | | | | | | | | | | | in POWER8: vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq In addition to adding the instructions themselves, it also adds support for the v1i128 type for intrinsics (Intrinsics.td, Function.cpp, and IntrinsicEmitter.cpp). http://reviews.llvm.org/D9081 llvm-svn: 238144
* Simplify and rename function overrideFunctionAttributes. NFC.Akira Hatanaka2015-05-231-13/+0
| | | | | | | This is in preparation to making changes needed to stop resetting NoFramePointerElim in resetTargetOptions. llvm-svn: 238079
* Store intrinsic ID by value in Function instead of a string lookup. NFC.Pete Cooper2015-05-191-26/+9
| | | | | | | | | | | | On 64-bit targets, Function has 4-bytes of padding in its struct layout. This uses the space for the intrinsic ID. It is set and recalculated whenever the function name is set. This is similar to the current behavior which clears the function from the intrinsic ID cache when its renamed. The intrinsic cache itself is removed as the only purpose was to speedup calls to getIntrinsicID() which now just reading the new field in the struct. Reviewed by Duncan. http://reviews.llvm.org/D9836 llvm-svn: 237642
* Move Function::lookupIntrinsicID to a static method. NFCPete Cooper2015-05-191-15/+14
| | | | llvm-svn: 237641
* Add function entry count metadata.Diego Novillo2015-05-131-0/+19
| | | | | | | | | | | | | | | | | | | | Summary: This adds three Function methods to handle function entry counts: setEntryCount() and getEntryCount(). Entry counts are stored under the MD_prof metadata node with the name "function_entry_count". They are unsigned 64 bit values set by profilers (instrumentation and sample profiler changes coming up). Added documentation for new profile metadata and tests. Reviewers: dexonsmith, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9628 llvm-svn: 237260
* Replace branch-to-unreachable with assertion.David Blaikie2015-05-081-4/+2
| | | | llvm-svn: 236893
* Let llc and opt override "-target-cpu" and "-target-features" via command lineAkira Hatanaka2015-05-061-0/+13
| | | | | | | | | | | options. This commit fixes a bug in llc and opt where "-mcpu" and "-mattr" wouldn't override function attributes "-target-cpu" and "-target-features" in the IR. Differential Revision: http://reviews.llvm.org/D9537 llvm-svn: 236677
* Add missing dereferenceable_or_null gettersSanjoy Das2015-05-061-0/+6
| | | | | | | | | | | | | | | | | Summary: Add missing dereferenceable_or_null getters required for http://reviews.llvm.org/D9253 change. Separated from the D9253 review. Patch by Artur Pilipenko! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9499 llvm-svn: 236615
* IR: Add Function metadata attachmentsDuncan P. N. Exon Smith2015-04-241-0/+3
| | | | | | | | Add IR support for `Metadata` attachments. Assembly and bitcode support will follow shortly, but for now we just have unit tests. This is part of PR23340. llvm-svn: 235783
* IR: Use a bitmask to access GlobalObject subclass dataDuncan P. N. Exon Smith2015-04-241-3/+5
| | | | | | | | Make room for more than just `Function::isMaterializable()` in the `GlobalObject` subclass data bitfield. Since we're treating it like a bitfield, change `Function::Function()` to zero-out the whole thing. llvm-svn: 235770
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
* [opaque pointer type] Avoid using PointerType::getElementType when parsing IRDavid Blaikie2015-04-061-4/+3
| | | | | | | | | | A few calls are left in for error checking - but I'm commenting those out & trying to build some IR tests (aiming for Argument Promotion to start with). When I get any of these tests passing I may add flag to disable the checking so I can add tests that pass with the assertion in place. llvm-svn: 234206
* InstCombine: propagate deref via new addDereferenceableAttrRamkumar Ramachandra2015-02-141-0/+6
| | | | | | | | | | | | | | | | | The "dereferenceable" attribute cannot be added via .addAttribute(), since it also expects a size in bytes. AttrBuilder#addAttribute or AttributeSet#addAttribute is wrapped by classes Function, InvokeInst, and CallInst. Add corresponding wrappers to AttrBuilder#addDereferenceableAttr. Having done this, propagate the dereferenceable attribute via gc.relocate, adding a test to exercise it. Note that -datalayout is required during execution over and above -instcombine, because InstCombine only optionally requires DataLayoutPass. Differential Revision: http://reviews.llvm.org/D7510 llvm-svn: 229265
* Masked Gather and Scatter Intrinsics.Elena Demikhovsky2015-02-081-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gather and Scatter are new introduced intrinsics, comming after recently implemented masked load and store. This is the first patch for Gather and Scatter intrinsics. It includes only the syntax, parsing and verification. Gather and Scatter intrinsics allow to perform multiple memory accesses (read/write) in one vector instruction. The intrinsics are not target specific and will have the following syntax: Gather: declare <16 x i32> @llvm.masked.gather.v16i32(<16 x i32*> <vector of ptrs>, i32 <alignment>, <16 x i1> <mask>, <16 x i32> <passthru>) declare <8 x float> @llvm.masked.gather.v8f32(<8 x float*><vector of ptrs>, i32 <alignment>, <8 x i1> <mask>, <8 x float><passthru>) Scatter: declare void @llvm.masked.scatter.v8i32(<8 x i32><vector value to be stored> , <8 x i32*><vector of ptrs> , i32 <alignment>, <8 x i1> <mask>) declare void @llvm.masked.scatter.v16i32(<16 x i32> <vector value to be stored> , <16 x i32*> <vector of ptrs>, i32 <alignment>, <16 x i1><mask> ) Vector of ptrs - a set of source/destination addresses, to load/store the value. Mask - switches on/off vector lanes to prevent memory access for switched-off lanes vector of ptrs, value and mask should have the same vector width. These are code examples where gather / scatter should be used and will allow function vectorization ;void foo1(int * restrict A, int * restrict B, int * restrict C) { ; for (int i=0; i<SIZE; i++) { ; A[i] = B[C[i]]; ; } ;} ;void foo3(int * restrict A, int * restrict B) { ; for (int i=0; i<SIZE; i++) { ; A[B[i]] = i+5; ; } ;} Tests will come in the following patches, with CodeGen and Vectorizer. http://reviews.llvm.org/D7433 llvm-svn: 228521
* Revert GCStrategy ownership changesPhilip Reames2015-01-261-6/+0
| | | | | | | | | | | | This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways. The bugs were: - Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely. - GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times. Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/. llvm-svn: 227109
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-161-0/+6
| | | | | | | | | | | | Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions. Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance. In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.) Differential Revision: http://reviews.llvm.org/D6811 llvm-svn: 226311
* getMangledTypeStr: clarify how it mangles types, and add testsPhilip Reames2015-01-141-0/+4
| | | | | | | | | "Write a set of tests that show how name mangling is done for overloaded intrinsics." These happen to use gc.relocates to exercise the codepath in question, but is not a GC specific test. Patch by: artagnon@gmail.com Differential Revision: http://reviews.llvm.org/D6915 llvm-svn: 226056
* Masked Load/Store - Changed the order of parameters in intrinsics.Elena Demikhovsky2014-12-251-2/+14
| | | | | | | No functional changes. The documentation is coming. llvm-svn: 224829
* The leak detector is dead, long live asan and valgrind.Rafael Espindola2014-12-221-15/+0
| | | | | | | In resent times asan and valgrind have found way more memory management bugs in llvm than the special purpose leak detector. llvm-svn: 224703
* Masked Load / Store Intrinsics - the CodeGen part.Elena Demikhovsky2014-12-041-2/+16
| | | | | | | | | | | | | | | | | | 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
* Prologue supportPeter Collingbourne2014-12-031-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Masked Vector Load and Store Intrinsics."Duncan P. N. Exon Smith2014-11-281-16/+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
* 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-231-2/+16
| | | | | | | | | | | | | | 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
* Extend intrinsic name mangling to support arrays, named structs, and ↵Philip Reames2014-11-121-6/+28
| | | | | | | | | | | | | function types. Currently, we have a type parameter mechanism for intrinsics. Rather than having to specify a separate intrinsic for each combination of argument and return types, we can specify a single intrinsic with one or more type parameters. These type parameters are passed explicitly to Intrinsic::getDeclaration or can be specified implicitly in the naming of the intrinsic function in an LL file. Today, the types are limited to integer, floating point, and pointer types. With a goal of supporting symbolic targets for patchpoints and statepoints, this change adds support for function types. The change also includes support for first class aggregate types (named structures and arrays) since these appear in function types we've encountered. Reviewed by: atrick, ributzka Differential Revision: http://reviews.llvm.org/D4608 llvm-svn: 221742
* Don't ever call materializeAllPermanently during LTO.Rafael Espindola2014-10-241-0/+9
| | | | | | | | | | To do this, change the representation of lazy loaded functions. The previous representation cannot differentiate between a function whose body has been removed and one whose body hasn't been read from the .bc file. That means that in order to drop a function, the entire body had to be read. llvm-svn: 220580
OpenPOWER on IntegriCloud