[aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler
White, Derek
Derek.White at cavium.com
Tue Jun 5 21:48:41 UTC 2018
Hi Dmitrij,
That looks like it could help.
The related question I've had on the back-burner for a while is WHY are we saving/restoring 42 registers in gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier?
We don't do that around any other calls to call_VM_leaf.
No other port saves the entire register set, even the arm64 port. They just save a few registers that are in use.
- Derek
> -----Original Message-----
> From: aarch64-port-dev [mailto:aarch64-port-dev-
> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko
> Sent: Tuesday, June 05, 2018 3:46 PM
> To: hotspot-compiler-dev at openjdk.java.net; aarch64-port-
> dev at openjdk.java.net
> Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load
> and stores in macroAssembler
>
> Hi all,
>
> please review small patch for 8204353 - AARCH64: optimize FPU load and
> stores in macroAssembler
>
> This patch optimize fpu stores and loads by using ld1/st1 instructions which
> handle 4 registers instead of ldp/stp (2 registers). It makes respective code
> up to 2 times smaller. Thus it has more changes to be optimized in CPU.
>
>
> Testing: I run hotspot jtreg compiler tests as sanity with patched and
> unpatched build. No new failures found.
>
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8204353
>
> webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/
>
>
> Thanks,
>
> Dmitrij
More information about the hotspot-compiler-dev
mailing list