similar to: About Stackmap section

Jordon, I just submitted a change to the docs to hopefully address your confusion.  Can you take a look and let me know if you have further questions?  Start with the revised Stack Map Format section. Philip p.s. I just submitted this and it'll take a few minutes to refresh.  In the meantime, you could look at the diff for 346405. On 11/2/18 2:52 PM, Jordan Rudd via llvm-dev wrote:

Hi, I'm trying to build a gc using the statepoint-example strategy. However, after hours of searching, reading documentation and trying to find code examples online, I cannot figure out how to access the Stack Map. The documentation for statepoint-example says: The stack map format generated by this GC strategy can be found in the Stack Map

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

Dear All I need to create a pass that is triggered to run at a specific point during runtime. Also, this pass needs to have access to object file and to be able to modify the original IR. Any idea how to make such pass? Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department Faculty of Engineering - Benha University E-JUST PhD Student Computer Science & Engineering Dept.

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to

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

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

Dear All I have some questions about how to use patchpoint intrinsic: 1- The function that is provided as argument to the intrinsic call, where does it belong? I'm making a pass to change a given IR file and add call to patchpoint. Where should I put this function? In the pass or in the same IR file or in another IR and include it or what? 2- When actually this code is patched into the

> 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/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 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

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

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: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

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

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

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