similar to: Vector Splitting for Stackmap Operands

Hey Guys ! I'm interested to participate in Google Summer of Code 2018 for LLVM. Any Projects (new features or reimplementation) related to recent " Meltdown & Spectre " Problem. I'm a beginner in Compiler Technology. Could you please recommend some videos or blog post about "*Introduction to LLVM internals ". *Because I find it difficult to understand LLVM IR

Hi Hal, no, as far as I can recall we don’t make that guarantee for StackMap Records. Although, since we record the StackMap Records in function order and in instruction order inside a function this has always been true, but that wasn’t intentional. This format shouldn’t change this, but it also isn’t something that we programmatically enforce. Do you depend on that behavior? -Juergen > On

> 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

On 10/17/13 10:39 PM, Andrew Trick wrote: > This is a proposal for adding Stackmaps and Patchpoints to LLVM. The > first client of these features is the JavaScript compiler within the > open source WebKit project. > I have a couple of comments on your proposal. None of these are major enough to prevent submission. - As others have said, I'd prefer an experimental namespace

On 10/22/13 10:34 AM, Filip Pizlo wrote: > On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > >> On 10/17/13 10:39 PM, Andrew Trick wrote: >>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>> first client of these features is the JavaScript compiler within the >>> open source WebKit project.

On Oct 23, 2013, at 7:26 PM, Philip Reames <listmail at philipreames.com> wrote: > On 10/23/13 5:38 PM, Andrew Trick wrote: >> >> On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com> wrote: >> >>>> The implementation of the two intrinsics is actually very similar. In this case, the difference would be that llvm.stackmap does not

Dear All My MSc was about implementing some kind of On stack replacement in LLVM to enhance security by obfuscating running code periodically. I've tried to implement this job in JIT, but I couldn't. So I implemented it in interpreter, as an initial step. However, now I'm trying to make it in JIT. My first step is to extract function state at an arbitrary point. So, I interrupt

On 10/23/13 10:03 PM, Andrew Trick wrote: > > On Oct 23, 2013, at 7:26 PM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> On 10/23/13 5:38 PM, Andrew Trick wrote: >>> >>> On Oct 23, 2013, at 5:27 PM, Philip Reames >>> <listmail at philipreames.com <mailto:listmail at

On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > On 10/17/13 10:39 PM, Andrew Trick wrote: >> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >> first client of these features is the JavaScript compiler within the >> open source WebKit project. >> > I have a couple of comments on your proposal. None of these

On 10/22/13 10:48 PM, Andrew Trick wrote: > I'll respond to a few questions below. I'll start a new thread for GC > discussion. Good idea. Thanks. > > On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >>> Now with regard to patching. I think llvm.patchpoint is generally

Dear All I need to read the stackmap section at runtime of the inspected application. I've read the documentation of stackmap and found this paragraph: "A JIT compiler can easily access this section by providing its own memory manager via the LLVM C API LLVMCreateSimpleMCJITMemoryManager(). When creating the memory manager, the JIT provides a callback:

I'll respond to a few questions below. I'll start a new thread for GC discussion. On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: >> Now with regard to patching. I think llvm.patchpoint is generally useful for any type of patching I can imagine. It does look like a call site in IR, and it’s nice to be able to leverage calling conventions to inform

Hello, I'm currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in

On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote: > On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > >> On 10/22/13 10:34 AM, Filip Pizlo wrote: >>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >>> >>>> On 10/17/13 10:39 PM, Andrew Trick wrote:

On 10/23/13 5:38 PM, Andrew Trick wrote: > > On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >>> The implementation of the two intrinsics is actually very similar. >>> In this case, the difference would be that llvm.stackmap does not >>> reserve space for patching, while

On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com> wrote: >> The implementation of the two intrinsics is actually very similar. In this case, the difference would be that llvm.stackmap does not reserve space for patching, while llvm.patchpoint does. > I'm slightly confused by this given that stackmap takes an argument indicating the number of nops to emit

Hi all, I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { entry: call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) ret

This is a proposal for adding Stackmaps and Patchpoints to LLVM. The first client of these features is the JavaScript compiler within the open source WebKit project. A Stackmap is a record of variable locations (registers and stack offsets) at a particular instruction address. A Patchpoint is an instruction address at which space is reserved for patching a new instruction sequence at runtime.

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

On Fri, Oct 18, 2013 at 1:39 AM, Andrew Trick <atrick at apple.com> wrote: > > The initial documentation and patches name these intrinsics in a > "webkit" namespace. This clarifies their current purpose and conveys > that they haven't been standardized for other JITs yet. If someone on > the on the dev list says "yes we want to use these too, just the way