Adding an intrinsic to the interpreter
john.r.rose at oracle.com
Tue Sep 15 04:42:39 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev