search for: getfieldptr

...art). The callback method will resolve the type and patch the store/load instruction so that the correct address is used (exactly like the JIT function callback compiles a method and patch the call) Now there is one issue to deal with here: how to represent the intrinsic? It can either be 1) llvm.getfieldptr.{type} or 2) have two kinds of intrinsics llvm.getfield.{type} and llvm.storefield.{type}. I'd prefer using 1) since its closer to the LLVM instruction set (GetElementPtrInst), however there may be some tricky issues on where and how the callback function must patch the code. For example, how...

...od will resolve the type and patch the store/load > instruction so that the correct address is used (exactly like the JIT > function callback compiles a method and patch the call) > > Now there is one issue to deal with here: how to represent the > intrinsic? It can either be 1) llvm.getfieldptr.{type} or 2) have two > kinds of intrinsics llvm.getfield.{type} and llvm.storefield.{type}. > > I'd prefer using 1) since its closer to the LLVM instruction set > (GetElementPtrInst), however there may be some tricky issues on where > and how the callback function must patch th...

...type and patch the store/load >> instruction so that the correct address is used (exactly like the JIT >> function callback compiles a method and patch the call) >> >> Now there is one issue to deal with here: how to represent the >> intrinsic? It can either be 1) llvm.getfieldptr.{type} or 2) have two >> kinds of intrinsics llvm.getfield.{type} and llvm.storefield.{type}. >> >> I'd prefer using 1) since its closer to the LLVM instruction set >> (GetElementPtrInst), however there may be some tricky issues on where >> and how the callback fu...

...ic would be only valid if we jit, and would be lowered only in > the codegen part (don't know yet if it would be in the target > dependent > or target independent part). > > Now there is one issue to deal with here: how to represent the > intrinsic? It can either be 1) llvm.getfieldptr.{type} or 2) have two > kinds of intrinsics llvm.getfield.{type} and llvm.storefield.{type}. I don't think this is really the right way to go. Can you give an example snippet of Java code that would need this and what you are proposing? With a concrete example that shows how the lazy...