RFR(S):8242429:Better implementation for signed extract
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Mon Apr 13 08:41:21 UTC 2020
Hi Eric,
I was confused at first by what "signed extract" means.
It should be "sign extract".
Overall, the changes look good.
One comment:
(i >> 31) >>> 31 ==> i >>> 31
The shift count value is irrelevant here, isn't it?
So, the transformation can be generalized to:
(i >> n) >>> 31 ==> i >>> 31
Best regards,
Vladimir Ivanov
On 09.04.2020 15:17, Eric Liu wrote:
> Hi,
>
> This is a small enhancement for C2 compiler.
>
>
> For java code "(i >> 31) >>> 31", it can be optimized to "i >>> 31".
> AArch64 has implemented this in back-end match rules, while AMD64
> hasn’t.
>
> Indeed, this pattern can be optimized in mid-end by adding some simple
> transformations. Besides, "0 - (i >> 31)" could also be optimized to
> "i >>> 31".
>
> This patch adds two conversions:
>
> 1. URShiftINode: (i >> 31) >>> 31 ==> i >>> 31
>
> +------+ +----------+
> | Parm | | ConI(31) |
> +------+ +----------+
> | / |
> | / |
> | / |
> +---------+ |
> | RShiftI | |
> +---------+ |
> \ |
> \ |
> \ |
> +----------+
> | URShiftI |
> +----------+
>
> 2. SubINode: 0 - (i >> 31) ==> i >>> 31
>
> +------+ +----------+
> | Parm | | ConI(31) |
> +------+ +----------+
> \ |
> \ |
> \ |
> \ |
> +---------+ +---------+
> | ConI(0) | | RShiftI |
> +---------+ +---------+
> \ |
> \ |
> \ |
> +------+
> | SubI |
> +------+
>
> With this patch, these two graghs above both can be optimized to below:
>
> +------+ +----------+
> | Parm | | ConI(31) |
> +------+ +----------+
> | /
> | /
> | /
> | /
> +----------+
> | URShiftI |
> +----------+
>
> This patch solved the same issue for long type and also removed the
> relevant match rules in "aarch64.ad" which become useless now.
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8242429
> Webrev: http://cr.openjdk.java.net/~yzhang/ericliu/8242429/webrev.00/
>
> [Tests]
> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
> No new failure found.
>
>
> --
> Thanks,
> Eric
>
More information about the hotspot-compiler-dev
mailing list