[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