summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer
Commit message (Collapse)AuthorAgeFilesLines
...
* Bitcode: Fix reading and writing of ConstantDataVectors of halfsJustin Bogner2016-01-061-12/+3
| | | | | | | | | | | | In r254991 I allowed ConstantDataVectors to contain elements of HalfTy, but I missed updating the bitcode reader and writer to handle this, so now we crash if we try to emit bitcode on programs that have constant vectors of half. This fixes the issue and adds test coverage for reading and writing constant sequences in bitcode. llvm-svn: 256982
* Rename MDValue* to Metadata* (NFC)Teresa Johnson2015-12-292-11/+11
| | | | | | | Renamed MDValue* to Metadata*, and MDValueToValIDMap to MetadataToIDs, as per review for r255909. llvm-svn: 256593
* Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-28/+8
| | | | | | | | | | | | | | | | | 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-8/+28
| | | | | | | | | | 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-28/+8
| | | | | | | | | | | | | | | | 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-8/+28
| | | | | | | | 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-28/+8
| | | | | | | | | | | | | | 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
* Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributesVaivaswatha Nagaraj2015-12-161-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
* add fast-math-flags to 'call' instructions (PR21290)Sanjay Patel2015-12-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp) to call instructions in IR. Follow-up patches would use these flags in LibCallSimplifier, add support to clang, and extend FMF to the DAG for calls. Motivating example: %y = fmul fast float %x, %x %z = tail call float @sqrtf(float %y) We'd like to be able to optimize sqrt(x*x) into fabs(x). We do this today using a function-wide attribute for unsafe-math, but we really want to trigger on the instructions themselves: %z = tail call fast float @sqrtf(float %y) because in an LTO build it's possible that calls with fast semantics have been inlined into a function with non-fast semantics. The code changes and tests are based on the recent commits that added "notail": http://reviews.llvm.org/rL252368 and added FMF to fcmp: http://reviews.llvm.org/rL241901 Differential Revision: http://reviews.llvm.org/D14707 llvm-svn: 255555
* [IR] Remove terminatepadDavid Majnemer2015-12-141-15/+0
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-33/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* Macro debug info support in LLVM IRAmjad Aboud2015-12-101-0/+28
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* [ThinLTO] Add MODULE_CODE_METADATA_VALUES recordTeresa Johnson2015-11-202-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is split out from the ThinLTO metadata mapping patch http://reviews.llvm.org/D14752. To avoid needing to parse the module level metadata during function importing, a new module-level record is added which holds the number of module-level metadata values. This is required because metadata value ids are assigned implicitly during parsing, and the function-level metadata ids start after the module-level metadata ids. I made a change to this version of the code compared to D14752 in order to add more consistent and thorough assertion checking of the new record value. We now unconditionally use the record value to initialize the MDValueList size, and handle it the same in parseMetadata for all module level metadata cases (lazy loading or not). Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14825 llvm-svn: 253668
* Use a different block id for block of metadata kind recordsTeresa Johnson2015-11-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function blocks (for metadata attached to instructions). For ThinLTO we want to delay the parsing of module level metadata until all functions have been imported from that module (there is some bookkeeping used to suture it up when we read it during a post-pass). However, we do need the METADATA_KIND records when parsing the function body during importing, since those kinds are used as described above. To simplify identification and parsing of just the block containing the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID). Support older bitcode without the new block id as well. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D14654 llvm-svn: 253154
* use range-based for loop; NFCISanjay Patel2015-11-131-4/+3
| | | | llvm-svn: 253048
* [OperandBundles] Identify operand bundles with both their names and IDsSanjoy Das2015-11-101-1/+1
| | | | | | | No code uses this functionality yet. This change just exposes information / structure that was already present. llvm-svn: 252644
* [Bitcode] Add enums for call instruction markers and flags. NFC.Akira Hatanaka2015-11-071-3/+5
| | | | | | | | | | This commit adds enums in LLVMBitCodes.h to improve readability and maintainability. This is a follow-up to r252368 which was discussed here: http://reviews.llvm.org/D12923 llvm-svn: 252395
* [OperandBundles] Rename accessor, NFCSanjoy Das2015-11-071-1/+1
| | | | | | Rename getOperandBundle to getOperandBundleAt since that's more obvious. llvm-svn: 252388
* Add 'notail' marker for call instructions.Akira Hatanaka2015-11-061-1/+2
| | | | | | | | | | | | This marker prevents optimization passes from adding 'tail' or 'musttail' markers to a call. Is is used to prevent tail call optimization from being performed on the call. rdar://problem/22667622 Differential Revision: http://reviews.llvm.org/D12923 llvm-svn: 252368
* Add a new attribute: norecurseJames Molloy2015-11-061-0/+2
| | | | | | This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
* Fix Abbrev emission in WriteIdentificationBlockMehdi Amini2015-11-051-1/+2
| | | | | | | This Abbrev was not emitted and basically unused, just leacking there. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252110
* Clang format a few prior patches (NFC)Teresa Johnson2015-11-021-22/+30
| | | | | | | I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251812
* Add an (optional) identification block in the bitcodeMehdi Amini2015-10-261-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release. This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information. The bitcode reader will dump this information alongside any error it reports. The optional block also includes an "epoch" number, monotonically increasing when incompatible changes are made to the bitcode. The reader will reject bitcode whose epoch is different from the one expected. Differential Revision: http://reviews.llvm.org/D13666 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 251325
* Pass FunctionInfoIndex by reference to WriteFunctionSummaryToFile (NFC)Teresa Johnson2015-10-191-8/+8
| | | | | | Implemented suggestion by dblakie in review for r250704. llvm-svn: 250723
* BitcodeWriter: Stop using implicit ilist iterator conversion, NFCDuncan P. N. Exon Smith2015-10-132-30/+23
| | | | | | | | | | Now LLVMBitWriter compiles without implicit ilist iterator conversions. In these cases, the cleanest thing was to switch to range-based for loops. Since there wasn't much noise I converted sub-loops and parent loops as a drive-by. llvm-svn: 250144
* Fix combined function index abbrev (NFC)Teresa Johnson2015-10-081-3/+0
| | | | | | | | | | | | Removed an unused abbrev op in the VST_CODE_COMBINED_FNENTRY abbrev. I noticed while writing/testing an array string dumper for llvm-bcanalyze that the combined function's VST entry abbrevs contained an old field that I am not using. Everything was working fine since the bitcode writer and reader were in sync on how the record fields were actually being set up and interpreted. llvm-svn: 249691
* Support for function summary index bitcode sections and files.Teresa Johnson2015-10-042-27/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The bitcode format is described in this document: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view For more info on ThinLTO see: https://sites.google.com/site/llvmthinlto The first customer is ThinLTO, however the data structures are designed and named more generally based on prior feedback. There are a few comments regarding how certain interfaces are used by ThinLTO, and the options added here to gold currently have ThinLTO-specific names as the behavior they provoke is currently ThinLTO-specific. This patch includes support for generating per-module function indexes, the combined index file via the gold plugin, and several tests (more are included with the associated clang patch D11908). Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13107 llvm-svn: 249270
* [Bitcode][Asm] Teach LLVM to read and write operand bundles.Sanjoy Das2015-09-241-0/+55
| | | | | | | | | | | | | | | | | | Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
* [opaque pointer types] Add an explicit pointee type to alias records in the IRDavid Blaikie2015-09-171-1/+2
| | | | | | | | | | Since aliases actually use and verify their explicit type already, no further invalid testing is required here. The invalid.test:ALIAS-TYPE-MISMATCH case catches errors due to emitting a non-pointee type in the new format or a non-pointer type in the old format. llvm-svn: 247952
* Restore "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-171-19/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
* Revert "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-171-152/+19
| | | | | | | | | | Temporarily revert to fix some buildbot issues. One is a minor issue with a variable unused in NDEBUG mode. More concerning are some test failures on win7 that I need to dig into. This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d. llvm-svn: 247898
* Function bitcode index in Value Symbol Table and lazy reading supportTeresa Johnson2015-09-171-19/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247894
* Refactor string encoding checks in BitcodeWriter (NFC)Teresa Johnson2015-09-171-14/+23
| | | | llvm-svn: 247891
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
* [IR] Give catchret an optional 'return value' operandDavid Majnemer2015-08-151-0/+2
| | | | | | | | | | | Some personality routines require funclet exit points to be clearly marked, this is done by producing a token at the funclet pad and consuming it at the corresponding ret instruction. CleanupReturnInst already had a spot for this operand but CatchReturnInst did not. Other personality routines don't need to use this which is why it has been made optional. llvm-svn: 245149
* [IR] Add token typesDavid Majnemer2015-08-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* Rangify for loop, NFC.Yaron Keren2015-08-101-6/+3
| | | | llvm-svn: 244434
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-1/+2
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-311-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags, using `DW_TAG_variable` in their place Stop exposing the `tag:` field at all in the assembly format for `DILocalVariable`. Most of the testcase updates were generated by the following sed script: find test/ -name "*.ll" -o -name "*.mir" | xargs grep -l 'DILocalVariable' | xargs sed -i '' \ -e 's/tag: DW_TAG_arg_variable, //' \ -e 's/tag: DW_TAG_auto_variable, //' There were only a handful of tests in `test/Assembly` that I needed to update by hand. (Note: a follow-up could change `DILocalVariable::DILocalVariable()` to set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable` (as appropriate), instead of having that logic magically in the backend in `DbgVariable`. I've added a FIXME to that effect.) llvm-svn: 243774
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+58
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* Reserve some constant values for the Swift calling convention.Bob Wilson2015-07-281-0/+2
| | | | | | | | | | | Swift has a custom calling convention that also requires some new flags on arguments and one new attribute on alloca instructions. This patch does not include the implementation of that calling convention - that will be provided as part of the open-source release of Swift; this only reserves the bitcode constant values so that they are not used for other purposes. llvm-svn: 243379
* Add argmemonly attribute.Igor Laevsky2015-07-111-0/+2
| | | | | | | | This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
* Add support for fast-math flags to the FCmp instruction.James Molloy2015-07-101-1/+5
| | | | | | | | | | | | | | FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
* Revert the new EH instructionsDavid Majnemer2015-07-101-58/+0
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-0/+58
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* Add a DIModule metadata node to the IR.Adrian Prantl2015-06-291-0/+11
| | | | | | | | | | | | | | | | | | | It is meant to be used to record modules @imported by the current compile unit, so a debugger an import the same modules to replicate this environment before dropping into the expression evaluator. DIModule is a sibling to DINamespace and behaves quite similarly. In addition to the name of the module it also records the module configuration details that are necessary to uniquely identify the module. This includes the configuration macros (e.g., -DNDEBUG), the include path where the module.map file is to be found, and the isysroot. The idea is that the backend will turn this into a DW_TAG_module. http://reviews.llvm.org/D9614 rdar://problem/20965932 llvm-svn: 241017
* Use foreach loop over constant operands. NFC.Pete Cooper2015-06-252-5/+3
| | | | | | | A number of places had explicit loops over Constant::operands(). Just use foreach loops where possible. llvm-svn: 240694
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-233-3/+3
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
OpenPOWER on IntegriCloud