search for: prologues

...get-specific linker, image loader and exception handling system to specify. 3.5  Interaction with Code Generation The relatively simple and fixed size nature of the extended compact unwind information proposed here depends on observing certain restrictions on optimization that might affect code in prologues and epilogues. These restrictions were noted where relevant throughout this section. Here is a summary of those requirements:  1. Use of any preserved register must be delayed until all of the preserved registers have     been saved.  2. In the prologue of a function with a RBP-based frame, the tw...

Hello > The prologue length in .debug_line is 157 for clang generated one, whereas > it is 34 for gcc generated one. I am curious about the results of making > prologue generated by clang look similar with one generated by gcc. > Could anyone let me know why this difference exists and if it is for good > /better purposes than for gcc. ? 1. This is not function prologue length.

1. I would like to know why there is a difference in function prologue generated for same function with clang and gcc. Compiler options used for gcc were as follows: arm-linux-gnueabi-gcc all-types.c -w -march=armv7-a -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=vfp -g -lm -o all-types_gcc Compiler options used for clang were as follows: /usr/local/bin/clang all-types.c -w

...ception handling > system to specify. > > 3.5 Interaction with Code Generation > The relatively simple and fixed size nature of the extended compact > unwind information > proposed here depends on observing certain restrictions on optimization > that might affect code in > prologues and epilogues. These restrictions were noted where relevant > throughout this section. > Here is a summary of those requirements: > > 1. Use of any preserved register must be delayed until all of the > preserved registers have > been saved. > 2. In the prologue of a func...

...ecify. > > > > 3.5 Interaction with Code Generation > > The relatively simple and fixed size nature of the extended compact > > unwind information > > proposed here depends on observing certain restrictions on optimization > > that might affect code in > > prologues and epilogues. These restrictions were noted where relevant > > throughout this section. > > Here is a summary of those requirements: > > > > 1. Use of any preserved register must be delayed until all of the > > preserved registers have > > been saved. >...

[Proposed langref entry] The "patchable-prologue" attribute on a function is a general mechanism to control the form of a function's prologue in ways that make it easy to patch at runtime. Currently only one value is supported: # "hotpatch-compact" If a function is marked with "patchable-prologue"="hotpatch-compact" then: 1. The first instruction

...ception handling > system to specify. > > 3.5 Interaction with Code Generation > The relatively simple and fixed size nature of the extended compact > unwind information > proposed here depends on observing certain restrictions on optimization > that might affect code in > prologues and epilogues. These restrictions were noted where relevant > throughout this section. > Here is a summary of those requirements: > > 1. Use of any preserved register must be delayed until all of the > preserved registers have > been saved. > 2. In the prologue of a functio...

>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >> >> Could someone else chime in on what they'd like to see? > > Sanjoy's idea makes sense to me, but only if we never need to add > prefix/prologue data after functions are created. Are

Hi, I am instrumenting the stores in a program by inserting a function call (store_prologue) before every store instruction in the IR file. I set the prologue function's attribute to "AlwaysInline" using addFnAttr(). In the program the prologue function is defined as static inline. I am using opt to generate an optimized (inline the calls to the store prologue) using the

hi, I don't understand exactlly the difference among main function, prologue code, and call function. how the llvm JIT process them in details? the main function is a program start entry prologue code call yueqiang 2003/12/25

> On 2015-Oct-12, at 10:41, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Vedant Kumar wrote: >>>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >>>> >>>> Could someone else chime in on what

Hello Anton, Thanks for the reply. I have not specified optimization level explicitly during compilation. For GCC default is O0 ie., no optimization. Do you mean that clang uses other optimization level other than O0 ? Could you please clarify ? On Thu, Feb 16, 2012 at 6:52 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello > > > The prologue length in

If I understand correctly, you're saying that the C source definition of the prologue function is declared as static. If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name. As such, it will never get inlined as the instrumented code

> I don't understand exactlly the difference among main function, prologue > code, and call function. I'm not sure that I understand your question. LLVM abstracts away target-specific information like function prologs and epilogs. If you are curious about the typical arrangement used by unix systems with _start and main, LLVM does not have that. Basically it uses 'main'

I think most function redirection patching schemes are going to be mutually incompatible, so I'm not sure it makes sense to make this attribute a comma-separated list. I think Eric's and Dean's use case may be better addressed by a separate attribute. My recollection is that they want to add nop slides to the prologue and epilogue that can be hotpatched to enable and disable

Hi Eric, Eric Christopher wrote: > Two things: > > a) I'm not against this Great! > b) So, what's your use case? I've got something I'm idly working on with > someone else where we want patchable targets in both prologue and > epilogue (and some other places...), and am thinking of how to make this > someone generic enough to build off of there. We

David Majnemer wrote: > > > On Mon, Oct 12, 2015 at 11:00 AM, Duncan P. N. Exon Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 2015-Oct-12, at 10:41, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto:sanjoy at playingwithpointers.com>> wrote: > > >

Chris Lattner wrote: >>I don't understand exactlly the difference among main function, prologue >>code, and call function. >> >> > >I'm not sure that I understand your question. LLVM abstracts away >target-specific information like function prologs and epilogs. > >If you are curious about the typical arrangement used by unix systems with

Function's have three kinds of optional data: prefix data, prologue data, and personalities. We don't have a consistent way of storing this data, IMO. This RFC discusses a new way of managing optional data that makes llvm::Function cleaner, more consistent, and a little smaller. What do we do currently? ======================== Prefix and prologue data are attached to Functions via

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------