similar to: RFC: New function attribute "patchable-prologue"="<kind>"

Displaying 20 results from an estimated 20000 matches similar to: "RFC: New function attribute "patchable-prologue"="<kind>""

2016 Apr 06
2
RFC: New function attribute "patchable-prologue"="<kind>"
Reid Kleckner wrote: > I'm assuming this attribute won't affect inlining or other IPO in any > way, but you should probably mention that in the langref. To directly answer this, this is just a *mechanism* to implement linkonce_odr type linkage. This in itself does not imply in IPO restrictions, that should come directly from the linkage type. -- Sanjoy
2016 Apr 14
3
RFC: New function attribute "patchable-prologue"="<kind>"
Thanks for looping me in Eric! If I was going to suggest anything here, I'd like to think about a more general approach than a very specific attribute like this. My preference is something like "patchable-function"="kind,kind,..." (if that's even possible). This allows us to have common infrastructure for being able to implement different kinds of function-level
2016 Apr 14
2
RFC: New function attribute "patchable-prologue"="<kind>"
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
2016 Apr 07
2
RFC: New function attribute "patchable-prologue"="<kind>"
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
2010 Oct 27
1
[LLVMdev] Implementing the hotpatch attribute for X86
> I don't know how GCC handles this case. They may do the padding in the > compiler. You are going to have to look at exactly what GCC does and > whatever hotpatch loader Wine uses to figure out what to do, but it > will most likely be incompatible with the Windows implementation. Why? I don't see how this might be incompatible with what MS linker does; in any case the end
2015 Jul 09
5
[LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using
2010 Oct 26
0
[LLVMdev] Implementing the hotpatch attribute for X86
On Tue, Oct 26, 2010 at 7:27 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > On 10/26/10 5:24 PM, Michael Spencer wrote: >> The linker adds the padding. Also, the first instruction just has to >> be two bytes or longer. Not exactly two bytes. > How then does the linker know to add the padding? I assume there's a > PE-COFF attribute that will do that, Nope,
2016 Apr 29
2
RFC: XRay -- A Function Call Tracing System
TL;DR: At Google we use a call tracing system called XRay which inserts patchable instrumentation points into function entries and exits. If the community is interested, we'd like to contribute this system to the LLVM project. Many more details are contained in the whitepaper at: https://storage.googleapis.com/xray-downloads/whitepaper/XRayAFunctionCallTracingSystem.pdf Who's
2015 Oct 16
5
Managed Languages BOF @ Dev Meeting
Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build compilers for managed languages. We're curious to hear who's planning on attending and what topics you'd like to hear about. Depending on the expected audience, we're happy to do anything between a rough "what to expect getting started" to a down in the weeds working session on relevant optimization
2010 Oct 26
2
[LLVMdev] Implementing the hotpatch attribute for X86
On 10/26/10 5:24 PM, Michael Spencer wrote: > The linker adds the padding. Also, the first instruction just has to > be two bytes or longer. Not exactly two bytes. How then does the linker know to add the padding? I assume there's a PE-COFF attribute that will do that, but what about other file formats, like ELF or Mach-O? Bear in mind that I'm doing this for the Wine project, so
2018 Jan 26
4
[RFC] Improving compact x86-64 compact unwind descriptors
Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to
2015 Oct 12
3
[RFC] Clean up the way we store optional Function data
> 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
2014 May 27
6
[LLVMdev] [PATCH] Symbol offsets
Somehow this cover letter was dropped from my symbol offsets patch set: 1. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html 2. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html Original message ----------------- About a year ago a proposal suggesting symbol offsets was brought to this list[1]. This proposal goes hand-in-hand with the prefix data proposal[2]
2018 Jan 29
2
[RFC] Improving compact x86-64 compact unwind descriptors
Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
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: > > >
2018 Jan 27
0
[RFC] Improving compact x86-64 compact unwind descriptors
John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different
2010 Oct 26
2
[LLVMdev] Implementing the hotpatch attribute for X86
Hi, According to http://blogs.msdn.com/b/freik/archive/2006/03/07/x64-hotpatchability.aspx, 'hotpatchable' functions on x86 (and by extension, x86-64) are preceded by six bytes of padding and start with a two byte instruction. The problem is that, still being relatively unfamiliar with the x86 backend, I have no idea how to implement this for the 'hotpatch' attribute I just added.
2015 Oct 21
2
[RFC] Clean up the way we store optional Function data
I've done some measurements on this. The test program I have just calls Function::Create(), F->setPersonalityFn(), and then F->eraseFromParent() in a loop 2^20 times. Results: pre-patch --- min: 1.10s max: 1.13s avg: 1.11s post-patch --- min: 1.26s max: 1.35s avg: 1.29s So we expect to lose 0.2 seconds per 1 million functions (with personality functions) in a
2015 Oct 16
2
[RFC] Clean up the way we store optional Function data
Here is a WIP patch as promised: http://reviews.llvm.org/D13829 It uses a hungoff uselist to store optional data as needed. Some early objections from Duncan: - An extra one-time malloc() is required to set personality functions. - We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down. Is this overhead
2015 Oct 12
2
[RFC] Clean up the way we store optional Function data
>> 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