[15] RFR (L): 8241436: C2: Factor out C2-specific code from MacroAssembler

[Andrew Dinn]

Hi Vladimir,

On 25/03/2020 12:22, Vladimir Ivanov wrote:
> 
>>> I took the liberty and refactored aarch64, arm32, ppc64, s390x code
>>> along the way. I did a cross-build, but I ask maintainers to verify that
>>> it doesn't break anything.
>> I'm hoping I'll be able to test this on AArch64 today.
> 
> Thank you, Andrew. I'll wait for the results.
Well, we have some good news, some bad news and some ugly news.

 - the good news is that a patched tree builds and passes tier1 tests on
AArch64!

  - the bad news is that configuring --with-jvm-features=-compiler2
causes the build to fail :-/

  - the ugly news is that that configuration still fails to build when
your patch is omitted!!! :-P

The immediate problem is in sharedRuntime_aarch64.cpp where we have this
little snippet at line 47

  #if COMPILER2_OR_JVMCI
  #include "adfiles/ad_aarch64.hpp"
  #include "opto/runtime.hpp"
  #endif

Clearly, we are not going to find either an ad header or an opto header
in this config (where we have !COMPILER2 && JVMCI).

n.b. the corresponding include in sharedRuntime_x86_64.cpp is

  #ifdef COMPILER2
  #include "opto/runtime.hpp"
  #endif

I still need to investigate this thoroughly to see why the define was
extended to specify OR_JVMCI and why there is an explicit include of an
ad header. I suspect it is probably to do with dynamic computation of
register sets (used to decide whether to include fp in the alloc set on
AArch64).

It's not clear to me that this is a show-stopper for your patch. I think
this is entirely unrelated and needs a separate fix. An ultra-cautious
approach suggests delaying your patch until I get to the bottom of this.
However, if you would prefer I'm happy to let your patch go through and
leave this problem for a follow-up JIRA. Either way the -compiler2
option is not going to build on AArch64.

regards,


Andrew Dinn
-----------