summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer
Commit message (Collapse)AuthorAgeFilesLines
* Prologue supportPeter Collingbourne2014-12-032-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add and use Type::subtypes. NFC.Rafael Espindola2014-11-241-3/+2
| | | | llvm-svn: 222682
* Pass a reference to ValueEnumerator.Rafael Espindola2014-11-173-37/+36
| | | | | | NFC. This will just make it easier to use std::unique_ptr in a caller. llvm-svn: 222170
* Revert "IR: MDNode => Value"Duncan P. N. Exon Smith2014-11-112-5/+5
| | | | | | | | | | | | | | | | | Instead, we're going to separate metadata from the Value hierarchy. See PR21532. This reverts commit r221375. This reverts commit r221373. This reverts commit r221359. This reverts commit r221167. This reverts commit r221027. This reverts commit r221024. This reverts commit r221023. This reverts commit r220995. This reverts commit r220994. llvm-svn: 221711
* IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()Duncan P. N. Exon Smith2014-11-032-5/+5
| | | | | | | Change `Instruction::getAllMetadataOtherThanDebugLoc()` from a vector of `MDNode` to one of `Value`. Part of PR21433. llvm-svn: 221167
* IR: Reorder metadata bitcode serialization, NFCDuncan P. N. Exon Smith2014-10-211-12/+14
| | | | | | | | | Enumerate `MDNode`'s operands *before* the node itself, so that the reader requires less RAUW. Although this will cause different code paths to be hit in the reader, this should effectively be no functionality change. llvm-svn: 220340
* IR: Remove dead code in metadata bitcode writing, NFCDuncan P. N. Exon Smith2014-10-213-16/+12
| | | | | | | No one cares how many uses each metadata value has, so don't bother counting. llvm-svn: 220337
* correct const-ness with auto and dyn_castSanjay Patel2014-10-151-3/+3
| | | | | | | | | 1. Use const with autos. 2. Don't bother with explicit const in cast ops because they do it automagically. Thanks, David B. / Aaron B. / Reid K. llvm-svn: 219817
* Use 'auto' for easier reading; no functional change intended.Sanjay Patel2014-10-151-6/+3
| | | | llvm-svn: 219804
* Introduce LLVMWriteBitcodeToMemoryBuffer C API function.Peter Collingbourne2014-10-141-0/+8
| | | | llvm-svn: 219643
* Modernize raw_fd_ostream's constructor a bit.Rafael Espindola2014-08-251-3/+3
| | | | | | | | | | Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error. A create static method would be even better, but this patch is already a bit too big. llvm-svn: 216393
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* UseListOrder: Handle self-usersDuncan P. N. Exon Smith2014-07-311-3/+3
| | | | | | | | | | Correctly sort self-users (such as PHI nodes). I added a targeted test in `test/Bitcode/use-list-order.ll` and the final missing RUN line to tests in `test/Assembly`. This is part of PR5680. llvm-svn: 214417
* UseListOrder: Don't give constant IDs to GlobalValuesDuncan P. N. Exon Smith2014-07-311-3/+6
| | | | | | | | | | | Since initializers of GlobalValues are being assigned IDs before GlobalValues themselves, explicitly exclude GlobalValues from the constant pool. Added targeted test in `test/Bitcode/use-list-order.ll` and added two more RUN lines in `test/Assembly`. This is part of PR5680. llvm-svn: 214368
* UseListOrder: Visit global valuesDuncan P. N. Exon Smith2014-07-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When predicting use-list order, we visit functions in reverse order followed by `GlobalValue`s and write out use-lists at the first opportunity. In the reader, this will translate to *after* the last use has been added. For this to work, we actually need to descend into `GlobalValue`s. Added a targeted test in `use-list-order.ll` and `RUN` lines to the newly passing tests in `test/Bitcode`. There are two remaining failures in `test/Bitcode`: - blockaddress.ll: I haven't thought through how to model the way block addresses change the order of use-lists (or how to work around it). - metadata-2.ll: There's an old-style `@llvm.used` global array here that I suspect the .ll parser isn't upgrading properly. When it round-trips through bitcode, the .bc reader *does* upgrade it, so the extra variable (`i8* null`) has an extra use, and the shuffle vector doesn't match. I think the fix is to upgrade old-style global arrays (or reject them?) in the .ll parser. This is part of PR5680. llvm-svn: 214321
* Reapply "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-301-14/+55
| | | | | | | This reverts commit r214249, reapplying r214242 and r214243, now that r214270 has fixed the UB. llvm-svn: 214271
* UseListOrder: Fix undefined behaviourDuncan P. N. Exon Smith2014-07-301-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes undefined behaviour that caused the revert in r214249. The problem was two unsequenced operations on a `DenseMap<>`, giving different behaviour in GCC and Clang. This: DenseMap<T*, unsigned> DM; for (auto &X : ...) DM[&X] = DM.size() + 1; should have been: DenseMap<T*, unsigned> DM; for (auto &X : ...) { unsigned Size = DM.size(); DM[&X] = Size + 1; } Until r214242, this difference between compilers didn't matter. In r214242, `OrderMap::LastGlobalValueID` was introduced and compared against IDs, which in GCC were off-by-one my expectations. llvm-svn: 214270
* Revert "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-291-55/+14
| | | | | | | | | | | | This reverts commits r214242 and r214243 while I investigate buildbot failures [1][2][3]. I can't reproduce these failures locally, so if anyone can see what I've done wrong, I'd appreciate a note. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9840 [2]: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/14981 [3]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/15191 llvm-svn: 214249
* UseListOrder: Order GlobalValue uses after initializersDuncan P. N. Exon Smith2014-07-291-14/+55
| | | | | | | | | | | | To avoid unnecessary forward references, the reader doesn't process initializers of `GlobalValue`s until after the constant pool has been processed, and then in reverse order. Model this when predicting use-list order. This gets two more Bitcode tests passing with `llvm-uselistorder`. Part of PR5680. llvm-svn: 214242
* UseListOrder: Create a struct around OrderMap, NFCDuncan P. N. Exon Smith2014-07-291-1/+9
| | | | llvm-svn: 214241
* IR: Create the use-list order shuffle vector in-placeDuncan P. N. Exon Smith2014-07-291-4/+3
| | | | | | | Per David Blaikie's review of r214135, this is a more natural way to initialize. llvm-svn: 214184
* Bitcode: Correctly compare a Use against itselfDuncan P. N. Exon Smith2014-07-291-0/+3
| | | | | | | | | | | | | | | Fix the sort of expected order in the reader to correctly return `false` when comparing a `Use` against itself. This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm adding a `RUN` line using `llvm-uselistorder` for every test in `test/Bitcode` that passes. A few tests still fail, so I'll investigate those next. This is part of PR5680. llvm-svn: 214157
* IR: Optimize size of use-list order shuffle vectorsDuncan P. N. Exon Smith2014-07-281-6/+5
| | | | | | | | | Since we're storing lots of these, save two-pointers per vector with a custom type rather than using the relatively heavy `SmallVector`. Part of PR5680. llvm-svn: 214135
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-283-94/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
* Bitcode: Don't optimize constants when preserving use-list orderDuncan P. N. Exon Smith2014-07-251-0/+6
| | | | | | | | | | | | | | | | | | | | `ValueEnumerator::OptimizeConstants()` creates forward references within the constant pools, which makes predicting constants' use-list order difficult. For now, just disable the optimization. This can be re-enabled in the future in one of two ways: - Enable a limited version of this optimization that doesn't create forward references. One idea is to categorize constants by their "height" and make that the top-level sort. - Enable it entirely. This requires predicting how may times each constant will be recreated as its operands' and operands' operands' (etc.) forward references get resolved. This is part of PR5680. llvm-svn: 213953
* IPO: Add use-list-order verifierDuncan P. N. Exon Smith2014-07-251-7/+2
| | | | | | | | | | | | | | | | | | | | Add a -verify-use-list-order pass, which shuffles use-list order, writes to bitcode, reads back, and verifies that the (shuffled) order matches. - The utility functions live in lib/IR/UseListOrder.cpp. - Moved (and renamed) the command-line option to enable writing use-lists, so that this pass can return early if the use-list orders aren't being serialized. It's not clear that this pass is the right direction long-term (perhaps a separate tool instead?), but short-term it's a great way to test the use-list order prototype. I've added an XFAIL-ed testcase that I'm hoping to get working pretty quickly. This is part of PR5680. llvm-svn: 213945
* Add a dereferenceable attributeHal Finkel2014-07-181-0/+2
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Rename AlignAttribute to IntAttributeHal Finkel2014-07-181-1/+1
| | | | | | | | | | | | Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
* Roundtrip the inalloca bit on allocas through bitcodeReid Kleckner2014-07-161-2/+9
| | | | | | | | | | | | | This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
* IR: Add COMDATs to the IRDavid Majnemer2014-06-273-1/+54
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
* Convert a few loops to use ranges.Rafael Espindola2014-06-171-18/+15
| | | | llvm-svn: 211089
* IR: add "cmpxchg weak" variant to support permitted failure.Tim Northover2014-06-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
* Allow aliases to be unnamed_addr.Rafael Espindola2014-06-061-2/+2
| | | | | | | | | | | | | | | | | | Alias with unnamed_addr were in a strange state. It is stored in GlobalValue, the language reference talks about "unnamed_addr aliases" but the verifier was rejecting them. It seems natural to allow unnamed_addr in aliases: * It is a property of how it is accessed, not of the data itself. * It is perfectly possible to write code that depends on the address of an alias. This patch then makes unname_addr legal for aliases. One side effect is that the syntax changes for a corner case: In globals, unnamed_addr is now printed before the address space. llvm-svn: 210302
* Add a new attribute called 'jumptable' that creates jump-instruction tables ↵Tom Roeder2014-06-051-0/+2
| | | | | | | | | | | | for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-281-1/+3
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Convert a few loops to use ranges.Rafael Espindola2014-05-261-54/+51
| | | | llvm-svn: 209628
* Add 'nonnull', a new parameter and return attribute which indicates that the ↵Nick Lewycky2014-05-201-0/+2
| | | | | | pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
* [IR] Make {extract,insert}element accept an index of any integer type.Michael J. Spencer2014-05-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
* raw_ostream: Forward declare OpenFlags and include FileSystem.h only where ↵Benjamin Kramer2014-04-291-0/+1
| | | | | | necessary. llvm-svn: 207593
* Add 'musttail' marker to call instructionsReid Kleckner2014-04-241-1/+2
| | | | | | | | | | | | This is similar to the 'tail' marker, except that it guarantees that tail call optimization will occur. It also comes with convervative IR verification rules that ensure that tail call optimization is possible. Reviewers: nicholas Differential Revision: http://llvm-reviews.chandlerc.com/D3240 llvm-svn: 207143
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-1/+1
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These linkages were introduced some time ago, but it was never very clear what exactly their semantics were or what they should be used for. Some investigation found these uses: * utf-16 strings in clang. * non-unnamed_addr strings produced by the sanitizers. It turns out they were just working around a more fundamental problem. For some sections a MachO linker needs a symbol in order to split the section into atoms, and llvm had no idea that was the case. I fixed that in r201700 and it is now safe to use the private linkage. When the object ends up in a section that requires symbols, llvm will use a 'l' prefix instead of a 'L' prefix and things just work. With that, these linkages were already dead, but there was a potential future user in the objc metadata information. I am still looking at CGObjcMac.cpp, but at this point I am convinced that linker_private and linker_private_weak are not what they need. The objc uses are currently split in * Regular symbols (no '\01' prefix). LLVM already directly provides whatever semantics they need. * Uses of a private name (start with "\01L" or "\01l") and private linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm agrees with clang on L being ok or not for a given section. I have two patches in code review for this. * Uses of private name and weak linkage. The last case is the one that one could think would fit one of these linkages. That is not the case. The semantics are * the linker will merge these symbol by *name*. * the linker will hide them in the final DSO. Given that the merging is done by name, any of the private (or internal) linkages would be a bad match. They allow llvm to rename the symbols, and that is really not what we want. From the llvm point of view, these objects should really be (linkonce|weak)(_odr)?. For now, just keeping the "\01l" prefix is probably the best for these symbols. If we one day want to have a more direct support in llvm, IMHO what we should add is not a linkage, it is just a hidden_symbol attribute. It would be applicable to multiple linkages. For example, on weak it would produce the current behavior we have for objc metadata. On internal, it would be equivalent to private (and we should then remove private). llvm-svn: 203866
* IR: add a second ordering operand to cmpxhg for failureTim Northover2014-03-111-1/+3
| | | | | | | | | | | | | | | The syntax for "cmpxchg" should now look something like: cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic where the second ordering argument gives the required semantics in the case that no exchange takes place. It should be no stronger than the first ordering constraint and cannot be either "release" or "acq_rel" (since no store will have taken place). rdar://problem/15996804 llvm-svn: 203559
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-092-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-051-2/+2
| | | | | | class. llvm-svn: 202946
* Now that we have C++11, turn simple functors into lambdas and remove a ton ↵Benjamin Kramer2014-03-011-19/+9
| | | | | | | | of boilerplate. No intended functionality change. llvm-svn: 202588
* Store a DataLayout in Module.Rafael Espindola2014-02-251-3/+3
| | | | | | | | | | | | | | Now that DataLayout is not a pass, store one in Module. Since the C API expects to be able to get a char* to the datalayout description, we have to keep a std::string somewhere. This patch keeps it in Module and also uses it to represent modules without a DataLayout. Once DataLayout is mandatory, we should probably move the string to DataLayout itself since it won't be necessary anymore to represent the special case of a module without a DataLayout. llvm-svn: 202190
* Replace the F_Binary flag with a F_Text one.Rafael Espindola2014-02-241-1/+1
| | | | | | | | | After this I will set the default back to F_None. The advantage is that before this patch forgetting to set F_Binary would corrupt a file on windows. Forgetting to set F_Text produces one that cannot be read in notepad, which is a better failure mode :-) llvm-svn: 202052
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-4/+15
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
* Revert "Decouple dllexport/dllimport from linkage"Nico Rieck2014-01-141-15/+4
| | | | | | | | Revert this for now until I fix an issue in Clang with it. This reverts commit r199204. llvm-svn: 199207
OpenPOWER on IntegriCloud