similar to: Getting stack size of compiled functions from LLVM

On 5/28/2018 11:34 PM, Nicholas Chapman via llvm-dev wrote: > Hi all, > I'm trying to get the amount of stack memory used by the functions I > am JIT compiling with LLVM. > I have a host C++ program, and I want to be able to access the stack > size from the host C++ program. > > I see in PrologEpilogInserter.cpp that the computed stack size is read > from the

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

On 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

Hi all, I would like to propose a mechanism that would allow LLVM to fold null pointer checks into "nearby" memory operations, subject to runtime support. This is related to but not exactly the same as a proposal floated by Peter Collingbourne earlier [1]. The obvious use cases are managed languages like Java, C# and Go that require a null check on pointers before they're used in

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he >

Hi all, I'm trying to play with patchoint (with MCJIT and VMKit) and I don't understand something. I generate this call for my first patch point. Basically, I want to call f(0). %5 = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64( i64 42, ;; patch point id is 42 i32 0, ;; 0 bytes for the padding i8* bitcast (i32 (i32)* @f to i8*), ;; my function f i32 1,

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

> 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 Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction:

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

Hi, On 06/10/2013 09:13 AM, Jonas Wagner wrote: > Hi, > > I know that backend processes one function at a time, > is it somehow possible to do there a whole program analysis, > or could you give me some guidelines? > > The backend introduces a MachineFunctionPass, from which point on it is only possible to run FunctionPasses, otherwise the machine functions

On 3/18/16 12:33 PM, Quentin Colombet via llvm-dev wrote: > Hi Vivek, > >> On Mar 16, 2016, at 1:00 PM, vivek pandya via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hello, >> >> Probably this may be too late to start thinking about this project >> but I think this is particularly useful

Hi, I need to instrument the code in order to generate an event (call a certain function) whenever X instructions have been executed. I'm using MachineFunctionPass to get machine-dependent representation of each LLVM function in the program. However, such pass doesn't allow to modify such functions. Is there any other class so I can modify MachineFunctions? Thanks in advance, Raul. --

Hello, Probably this may be too late to start thinking about this project but I think this is particularly useful feature for LLVM. A quick use I can think of this is Implementing Inter-procedural Register Allocation ( for Research purpose ). I have start looking at the code for MachineFunctionPass, I think currently MachineModule class is not available ( the project work will include that ) but

On 7/8/11 4:49 PM, Andrew Ruef wrote: > I investigated the MachineFunctionPass (that is runOnMachineFunction, > I believe). A MachineFunctionPass is a class that you inherit from to write a transform that operates on MachineInstrs (i.e., native code instructions generated from the LLVM IR instructions). The runOnMachineFunction() method is its entry point (i.e., the code generator

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

I made a second MachineFunctionPass that can run on new PM and made it similar to the MachineFunctionPass for legacy PM. It seemed that the only required analysis used by it was MachineModuleInfo which I also made a new PM analysis for by separating it into 2 classes: 1 that holds the meta information specific to a module, and 1 that's the pass which holds an instance to the first class. The

I investigated the MachineFunctionPass (that is runOnMachineFunction, I believe). In my experimentation it didn't seem that the MachineFrameInfo was populated (it consistently said that the stack depth was 0, for example). I might have been doing something wrong? On Fri, Jul 8, 2011 at 5:21 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/8/11 4:09 PM, Andrew Ruef wrote: