Adding an intrinsic to the interpreter

[John Rose]

On Sep 14, 2015, at 11:35 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Thanks. Those patches provides a useful guide of changes required. If I take the plunge I would prefer to tackle getLong, as a quicker hack, rather than vectorizedMismatch in terms of the generated machine code.

I agree this is worth a first try.  Try to intrinsify the smaller bits first.
The interpreter has math intrinsics (AbstractInterpreter::java_lang_math_sqrt / vmIntrinsics::_dsqrt)
The enum in AbsInterp predates the vmIntrinsics enum, and there is duplication between them.

If we add new special cases to AbstractInterpreter, they might just vector through the Method::_intrinsic_id slot to a leaf C function.
(Perhaps different distinct leaf-function signatures get distinct MethodKind values.)
The extra indirections (via a function pointer table indexed by intrinsic_id) are noise in the interpreter.
The existing hardwired math functions could (in principle) be treated this way, as an additional cleanup.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150915/1923623c/attachment-0001.html>