[vector] Infrastructure for calling math routines in .s files

[Lupusoru, Razvan A]

Hi Vladimir,

Those were great suggestions. I have actually taken everything you mentioned into account (including removing the NO_FP changes out of this patch).

Please take a look at the updated version:
http://cr.openjdk.java.net/~rlupusoru/panama/webrev_callsvml_11/

Also, I separated the tests this time and you can review here. I can merge this patch separately:
http://cr.openjdk.java.net/~rlupusoru/panama/webrev_mathtests_00/

Thanks and have a great weekend!

--Razvan

-----Original Message-----
From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] 
Sent: Friday, May 18, 2018 7:25 PM
To: Lupusoru, Razvan A <razvan.a.lupusoru at intel.com>; panama-dev at openjdk.java.net
Subject: Re: [vector] Infrastructure for calling math routines in .s files

> So I am sending out the initial patch which adds infrastructure (plus one implementation - exp) in order to be able to call these assembly routines from JIT compiled code. In a subsequent patches, we will contribute the other implementations in form of assembly files.
> http://cr.openjdk.java.net/~rlupusoru/panama/webrev_callsvml_09/index.
> html

Wow, vector calls! Nice! :-)

My main concern is amount of changes in shared code needed. I'd like to see the logic somehow confined just to those vector stub calls.

Some suggestions:

   (1) introduce new node for calling vector stubs - CallLeafVector?
        - no need in CallLeafNode::has_vector_arguments_or_return()

   (2) Implement custom calling convention instead of extending c_calling_convention. It seems there is a need for a limited set of shapes (unary, binary, ?) and even having those cases hard-coded should be fine. It can simplify the patch in the following way:
        - have the logic factored out into platform-specific
vector_calling_convention() / vector_return_value();
        - get rid of T_VECTOR* basic types
        - no need to extend return_value in x86_64.ad for vector types

> Please take a look at the patch and let me know if you have any questions. I would like to point out that among changes there are also a few which make sure that compiler does not tag with "NO_FP" any calls that may end up calling methods that are using FP/vector code. This is quite important for Vector API since unlike auto-vectorizer, there may be live vector registers at any point in the code.

Doesn't it cause problems for floats/doubles in xmm registers then? I have some doubts all those cases are problematic, but, anyway, I suggest to handle it separately and focus on vector stub calls alone here.

Best regards,
Vladimir Ivanov