RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]

[Tobias Hartmann]

On Tue, 27 Apr 2021 09:40:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.
>
> Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - add missing stuff; change according to review comment
>  - Merge branch 'master' into canon_opt
>  - canonicalize well-chosen intrinsic methods

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1330:

> 1328:   LabelObj* L_done = new LabelObj();
> 1329: 
> 1330:   LIR_Opr temp = new_register(T_METADATA);

`temp` could be renamed to `klass`.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1339:

> 1337: 
> 1338:   __ branch_destination(L_not_prim->label());
> 1339:   __ move(new LIR_Address(receiver.result(), java_lang_Class::klass_offset(), T_ADDRESS), temp, NULL);

Why are you reloading the klass here?

Also, as @rwestrel explained in the RFR for [8211231](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030745.html), we need to be really careful when emitting branches in C1's LIR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616