summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser/LLLexer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ASMParser] Parse FP constants in non-C localesMeador Inge2016-06-021-2/+4
| | | | | | | | | | | This patch fixes PR25788, which allows for the parsing of floating-point constants in non-C locales. Patch by Antoine Pitrou! Differential Revision: http://reviews.llvm.org/D15375 llvm-svn: 271574
* AMDGPU/SI: Add amdgpu_kernel calling convention. Part 1.Nikolay Haustov2016-05-061-0/+1
| | | | | | | | | | | | | | | | | Summary: This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF. Also, in the future unused non-kernels may be optimized. For now, also accept SPIR_KERNEL for HCC frontend. Also, add bitcode compatibility tests for missing calling conventions except AVR_BUILTIN which doesn't have parse code. Reviewers: tstellarAMD, arsenm Subscribers: arsenm, joker.eph, llvm-commits llvm-svn: 268717
* Add the allocsize attribute to LLVM.George Burgess IV2016-04-121-0/+1
| | | | | | | | | | | | | | | | `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-0/+1
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* AMDGPU: Add a shader calling conventionNicolai Haehnle2016-04-061-0/+4
| | | | | | | | | | | This makes it possible to distinguish between mesa shaders and other kernels even in the presence of compute shaders. Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Differential Revision: http://reviews.llvm.org/D18559 llvm-svn: 265589
* Swift Calling Convention: add swiftcc.Manman Ren2016-04-051-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D17863 llvm-svn: 265480
* Swift Calling Convention: add swifterror attribute.Manman Ren2016-04-011-0/+1
| | | | | | | | | | | | A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-311-1/+5
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Restore "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-301-0/+1
| | | | | | | This restores commit 264869, with a fix for windows bots to properly escape '\' in the path when serializing out. Added test. llvm-svn: 264884
* Revert "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-301-1/+0
| | | | | | | | | This reverts commit r264869. I am seeing Windows bot failures due to the "\" in the path being mishandled at some point (seems to be interpreted wrongly at some point and llvm-as | llvm-dis is yielding some junk characters). Need to investigate. llvm-svn: 264871
* [ThinLTO] Serialize the Module SourceFileName to/from LLVM assemblyTeresa Johnson2016-03-301-0/+1
| | | | | | | | | | | | | | | | | | | Summary: This change serializes out and in the SourceFileName to LLVM assembly so that it is preserved through "llvm-dis | llvm-as". This is necessary to ensure that the global identifiers created for local values in the module summary index are the same even if the bitcode is streamed out and read back from LLVM assembly. Serializing the summary itself to LLVM assembly is in progress. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18588 llvm-svn: 264869
* Swift Calling Convention: add swiftself attribute.Manman Ren2016-03-291-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D17866 llvm-svn: 264754
* [AVR] Add calling convention parser tokensDylan McKay2016-03-031-0/+2
| | | | | | | | | | | | Summary: Adds the 'avr_intrcc' and 'avr_signalcc' IR calling convention tokens to the parser. Reviewers: arsenm Subscribers: dylanmckay, llvm-commits Differential Revision: http://reviews.llvm.org/D16348 llvm-svn: 262600
* Implemented Support of IA interrupt and exception handlers:Amjad Aboud2015-12-211-0/+1
| | | | | | | | http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html Differential Revision: http://reviews.llvm.org/D15567 llvm-svn: 256155
* Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributesVaivaswatha Nagaraj2015-12-161-0/+2
| | | | | | | | | | | | | | | | | | 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
* [IR] Remove terminatepadDavid Majnemer2015-12-141-1/+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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* [CXX TLS calling convention] Add CXX TLS calling convention.Manman Ren2015-12-041-0/+1
| | | | | | | | | | | | | | | | | | | | | This commit adds a new target-independent calling convention for C++ TLS access functions. It aims to minimize overhead in the caller by perserving as many registers as possible. The target-specific implementation for X86-64 is defined as following: Arguments are passed as for the default C calling convention The same applies for the return value(s) The callee preserves all GPRs - except RAX and RDI The access function makes C-style TLS function calls in the entry and exit block, C-style TLS functions save a lot more registers than normal calls. The added calling convention ties into the existing implementation of the C-style TLS functions, so we can't simply use existing calling conventions such as preserve_mostcc. rdar://9001553 llvm-svn: 254737
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-0/+1
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* Add 'notail' marker for call instructions.Akira Hatanaka2015-11-061-0/+1
| | | | | | | | | | | | 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/+1
| | | | | | 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
* HHVM calling conventions.Maksim Panchenko2015-09-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | HHVM calling convention, hhvmcc, is used by HHVM JIT for functions in translated cache. We currently support LLVM back end to generate code for X86-64 and may support other architectures in the future. In HHVM calling convention any GP register could be used to pass and return values, with the exception of R12 which is reserved for thread-local area and is callee-saved. Other than R12, we always pass RBX and RBP as args, which are our virtual machine's stack pointer and frame pointer respectively. When we enter translation cache via hhvmcc function, we expect the stack to be aligned at 16 bytes, i.e. skewed by 8 bytes as opposed to standard ABI alignment. This affects stack object alignment and stack adjustments for function calls. One extra calling convention, hhvm_ccc, is used to call C++ helpers from HHVM's translation cache. It is almost identical to standard C calling convention with an exception of first argument which is passed in RBP (before we use RDI, RSI, etc.) Differential Revision: http://reviews.llvm.org/D12681 llvm-svn: 248832
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix bug in method LLLexer::FP80HexToIntPairKarl Schimpf2015-08-311-1/+1
| | | | llvm-svn: 246489
* [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
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+7
| | | | | | | | | | 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
* Add argmemonly attribute.Igor Laevsky2015-07-111-0/+1
| | | | | | | | 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
* Revert the new EH instructionsDavid Majnemer2015-07-101-7/+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/+7
| | | | | | | | | | | | | | | 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
* ADT: Add a string APSInt constructor.Alex Lorenz2015-06-231-14/+1
| | | | | | | | | | | | This commit moves the APSInt initialization code that's used by the LLLexer class into a new APSInt constructor that constructs APSInts from strings. This change is useful for MIR Serialization, as it would allow the MILexer class to use the same APSInt initialization as LLexer when parsing immediate machine operands. llvm-svn: 240436
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* Fix doxygen comments. NFCFilipe Cabecinhas2015-06-071-10/+10
| | | | llvm-svn: 239250
* Add initial support for the convergent attribute.Owen Anderson2015-05-261-0/+1
| | | | llvm-svn: 238264
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* AsmParser/Writer: Handle symbolic constants in DI 'flags:'Duncan P. N. Exon Smith2015-02-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Parse (and write) symbolic constants in debug info `flags:` fields. This prevents a readability (and CHECK-ability) regression with the new debug info hierarchy. Old (well, current) assembly, with pretty-printing: !{!"...\\0016387", ...} ; ... [public] [rvalue reference] Flags field without this change: !MDDerivedType(flags: 16387, ...) Flags field with this change: !MDDerivedType(flags: DIFlagPublic | DIFlagRValueReference, ...) As discussed in the review thread, this isn't a final state. Most of these flags correspond to `DW_AT_` symbolic constants, and we might eventually want to support arbitrary attributes in some form. However, as it stands now, some of the flags correspond to other concepts (like `FlagStaticMember`); until things are refactored this is the simplest way to move forward without regressing assembly. llvm-svn: 230111
* AsmParser: Use StringRef for keyword comparisons, NFCDuncan P. N. Exon Smith2015-02-211-10/+9
| | | | | | | | Leverage `StringRef` inside keyword comparison macros. There's no reason to be so low-level here, and I'm about to add another `startswith()` use, so let's make it easy to read. llvm-svn: 230100
* AsmParser: Use do{}while(false) in macros, NFCDuncan P. N. Exon Smith2015-02-201-11/+21
| | | | | | | | | | | | | | `do { ... } while (false)` is standard macro etiquette for forcing instantiations into a single statement and requiring a `;` afterwards, making statement-like macros easier to reason about (and harder to use incorrectly). I'm about to modify the macros in `LexIdentifier()`. I noticed that the `KEYWORD` macro *does* follow the rule, so I thought I'd clean up the other macros to match (otherwise might not be worth changing, since the benefits of this pattern are fairly irrelevant here). llvm-svn: 230095
* AsmWriter/Bitcode: MDExpressionDuncan P. N. Exon Smith2015-02-131-0/+1
| | | | llvm-svn: 229023
* AsmWriter: MDSubprogram: Recognize DW_VIRTUALITY in 'virtuality'Duncan P. N. Exon Smith2015-02-131-0/+1
| | | | llvm-svn: 229015
* AsmWriter: MDCompositeType: Recognize DW_LANG in 'runtimeLang'Duncan P. N. Exon Smith2015-02-131-0/+1
| | | | llvm-svn: 229010
* AsmWriter: MDBasicType: Recognize DW_ATE in 'encoding'Duncan P. N. Exon Smith2015-02-131-5/+9
| | | | llvm-svn: 229006
* AsmParser: Recognize DW_TAG_* constantsDuncan P. N. Exon Smith2015-02-031-0/+6
| | | | | | | Recognize `DW_TAG_` constants in assembly, and output it by default for `GenericDebugNode`. llvm-svn: 228042
* Remove unused tokens in the ll lexer.Sean Silva2015-01-291-1/+0
| | | | | | Patch by Robin Eklind! llvm-svn: 227442
* IR: Add 'distinct' MDNodes to bitcode and assemblyDuncan P. N. Exon Smith2015-01-081-0/+3
| | | | | | | | | | | | | | | | | | Propagate whether `MDNode`s are 'distinct' through the other types of IR (assembly and bitcode). This adds the `distinct` keyword to assembly. Currently, no one actually calls `MDNode::getDistinct()`, so these nodes only get created for: - self-references, which are never uniqued, and - nodes whose operands are replaced that hit a uniquing collision. The concept of distinct nodes is still not quite first-class, since distinct-ness doesn't yet survive across `MapMetadata()`. Part of PR22111. llvm-svn: 225474
* AsmParser: Don't allow null bytes in BB labelsDavid Majnemer2014-12-101-1/+6
| | | | | | | Since Value objects can't have null bytes in their name, we shouldn't allow them in the labels of basic blocks. llvm-svn: 223907
* AsmParser: Don't crash if a null byte is inside a quoted stringDavid Majnemer2014-12-101-52/+33
| | | | | | | We don't allow Value* to have names which contain null bytes. The AsmParser should reject .ll files that try to do this. llvm-svn: 223869
* AsmParser: Verifier that the contents of a hex integer are hexDavid Majnemer2014-12-091-1/+7
| | | | llvm-svn: 223856
* AsmParser: Don't crash on short hex constants for fp128 typesDavid Majnemer2014-12-091-5/+7
| | | | | | | If we see 0xL01, treat it like 0xL00000000000000000000000000000001 instead of crashing. llvm-svn: 223811
* Prologue supportPeter Collingbourne2014-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud