Adding an intrinsic to the interpreter

[Coleen Phillimore]

On 9/15/15 12:42 AM, John Rose wrote:
> 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.

I'm not following this suggestion but not having the duplicate assembly 
interpreter entries for intrinsics in the interpreter would be really 
good, if we can do that.  Can you provide more details? I don't see it 
right now.  Using just Method::_intrinsic_id instead of the 
AbstractInterpreter::blah_entry is just one piece of this, right?

Thanks,
Coleen
>
> — John