search for: stackmaps

HI All, I am current working with SIMD instruction along with stackmap features. Recently I encountered a problem involving legalizing stackmap. In my stackmap, I record all the live values existing at the callsite. One of the operands in my stackmap is an illegal vector type for arm64 architecture ( *v4f64*) and requires vector splitting in order to legalize the node ( *v2f64*). However, I

...sis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps specifically but just end up affecting it; the last two will crash the stackmaps code. I think my takeaway is that at this late point in the pipeline, the stackmaps liveness code has to be the main consumer of this information, otherwise these kinds of bugs/behavior would have been noticed. So fi...

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the patchpoint/stackmap. For now it might be possible to just fix BranchFolder (and also TailDuplicatePass::TailDuplicate) to use a backwards an...

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

...lip 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: >>>> 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. >&gt...

> 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 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 are major enough to prevent submission. > > - As others have said, I'...

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

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

...lipreames.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: >>>>> 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 sub...

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. >>> >> I have a couple of comments on your proposal. None of these are major enough to prevent submission. >> >> - As o...

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 n...

Sounds good. I will add that to the StackMap documentation when I update it for v2. —Juergen > On Jul 10, 2015, at 9:40 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > No, but I've noticed that it is true in practice, and so I think that we should say something about it one way or another. Especially since, in switching to a fixed-size record format, binary searching now

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 re...

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily build the layout of an object at runtime, i.e., we don't know the layout of the object when we are emitting the code. And, we want to access to a field...

...oryManagerAllocateDataSectionCallback(). When LLVM creates this section, it invokes the callback and passes the section name. The JIT can record the in-memory address of the section at this time and later parse it to recover the stack map data. On Darwin, the stack map section name is "__llvm_stackmaps". The segment name is "__LLVM_STACKMAPS"." However I can't figure how to make LLVMCreateSimpleMCJITMemoryManager or LLVMMemoryManagerAllocateDataSectionCallback or make use of them. And I could not find examples for their useage. Any help is appreciated. Regards, Marwa Yu...

...gt;> 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. >>>>>>> >>>>>> I have a couple of comments on your proposal. None of these...

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

...te: >>>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com >>>> <mailto: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 are >>&gt...

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 the ELF-Branch. serializeToStackMapSection writes the information using MCStreamer, which seems to work properly. I'm using MCJIT with a custom memory manager to intercept the stackm...