On Thu, 23 Feb 2023 15:02:48 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
> > > Correct, `extsw` performs a `I2L` conversion. I had thought about this > > > already, but I think my current implementation is more efficient as it > > > combines register moves with the 64 bit extend. Your proposal would > > > generate separate extend and move instructions, right? > > > > > > Would it be possible to generate a biding cast + move and the recognize the > > pattern in the HS backend and optimize it away as a `extsw` ? > > At the moment, there is a forced indirection between the Java code and > downcall stub, so the JIT can not do any optimizations that have to take both > sides into account. The downcall stub is opaque to the JIT. (though, perhaps > in the long run we can add intrinsification of `linkToNative` that can > generate the code in the downcall stub as part of the JIT's own IR, which > would solve this) I meant generating `extsw` when emitting the stub (since when we emit the stub we can see the bindings). But I suppose the problem there is that the VM only sees low level bindings such as moves, it doesn't see bindings such as casts. ------------- PR: https://git.openjdk.org/jdk/pull/12708
