[vector] Fix build failures

[Paul Sandoz]

Ah, I see now, this is a result of the refactoring.

Clearly some compiler tool chains are more forgiving than others in their treatment of inline.  Out of curiosity did you try with the recommended version of gcc? 

I guess you don’t need to remove the inline on classify_unsafe_addr since it is only called from make_unsafe_address? Were you just trying to be consistent in case that method gets used externally?

I don’t know what the performance implications are here but we can revisit. I think it's ok to proceed. 

Paul.

> On May 8, 2020, at 3:39 AM, Qi Feng <Qi.Feng at arm.com> wrote:
> 
> Hi Paul,
> 
> Thanks for the review. I think the change to library_call.cpp is necessary,
> since situations are different in jdk/jdk and jdk/panama.
> 
> In jdk/jdk, `make_unsafe_address` is only used in library_call.cpp. Meanwhile in
> jdk/panama, it's also used in vectorIntrinsics.cpp. According to
> https://urldefense.com/v3/__https://isocpp.org/wiki/faq/inline-functions*inline-nonmember-fns__;Iw!!GqivPVa7Brio!Nc-yhyoYvMlQRvr-1xpbdU6bH9mJaVDLC6dsAbfGyLaj-1y88Kd4N5YTnAuMnRobOQ$ :
> 
>    Note: It's imperative that the function's definition (the part between the
>    {...}) be placed in a header file, unless the function is used only in a
>    single .cpp file. In particular, if you put the inline function's definition
>    into a .cpp file and you call it from some other .cpp file, you'll get an
>    "unresolved external" error from the linker.
> 
> Thanks,
> Qi
> 
> From: Paul Sandoz <paul.sandoz at oracle.com> 
> Sent: Thursday, May 7, 2020 11:38 PM
> To: Qi Feng <Qi.Feng at arm.com>
> Cc: panama-dev at openjdk.java.net; nd <nd at arm.com>
> Subject: Re: [vector] Fix build failures
> 
> Hi Qi,
> 
> Thanks for fixing the bad merge in aarch64.ad and fixing the signature in sharedRuntime_zero.cpp.
> 
> The change to library_call.cpp I am less certain about as prior to your change it is identical to that in jdk/jdk:
> 
>   http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/library_call.cpp#l2203
> 
> and the history shows those declarations have not changed.
> 
> Recently the recommended version of gcc was changed to 9.2.0 (from 8.3.0):
> 
>   https://bugs.openjdk.java.net/browse/JDK-8241721
>   https://hg.openjdk.java.net/jdk/jdk/rev/f2a0b262efea
> 
> Paul.
> 
> 
> On May 6, 2020, at 7:20 PM, Qi Feng <mailto:Qi.Feng at arm.com> wrote:
> 
> Hi,
> 
> This patch fixes zero variant build failure. The failure is caused by
> signature mismatch of function SharedRuntime::vector_calling_convention.
> 
> Another failure that occurs when building with gcc8 is fixed. The error
> message in this case is:
> 
>  builds/panama/temp2/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o: In function `LibraryCallKit::inline_vector_mem_operation(bool)':
>  repos/panama/src/hotspot/share/opto/vectorIntrinsics.cpp:580: undefined reference to `LibraryCallKit::make_unsafe_address(Node*&, Node*, unsigned long, BasicType, bool)'
>  builds/panama/temp2/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o: In function `LibraryCallKit::inline_vector_gather_scatter(bool)':
>  repos/panama/src/hotspot/share/opto/vectorIntrinsics.cpp:742: undefined reference to `LibraryCallKit::make_unsafe_address(Node*&, Node*, unsigned long, BasicType, bool)'
>  collect2: error: ld returned 1 exit status
>  lib/CompileJvm.gmk:181: recipe for target '/home/qifen01/builds/panama/temp2/support/modules_libs/java.base/server/libjvm.so' failed
>  make[3]: *** [/home/qifen01/builds/panama/temp2/support/modules_libs/java.base/server/libjvm.so] Error 1
> 
> Still another build failure on aarch64, which is caused by the
> duplication of instruct vmul8B/vmul16B and introduced in a recent
> merge, is fixed as well.
> 
> Webrev: http://cr.openjdk.java.net/~qfeng/panama/vectorapi/zero_build/webrev.00/
> 
> Thanks,
> Qi
>