CR for RFR 8140779

Berg, Michael C michael.c.berg at intel.com
Tue Nov 10 17:39:03 UTC 2015


This webrev resolves issues found during extensive testing.

http://cr.openjdk.java.net/~mcberg/8140779/webrev.04/

Thanks,
Michael

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Berg, Michael C
Sent: Friday, October 30, 2015 9:07 PM
To: Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net
Subject: RE: CR for RFR 8140779

Vladimir, Igor: I have uploaded the latest source at 

http://cr.openjdk.java.net/~mcberg/8140779/webrev.02/

Thanks,
Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Friday, October 30, 2015 1:16 AM
To: hotspot-compiler-dev at openjdk.java.net; Berg, Michael C
Subject: Re: CR for RFR 8140779

match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector().

Otherwise very nice cleanup. Thank you.

Igor, please, use RBT on x86 to execute a lot of tests.

Thanks,
Vladimir

On 10/30/15 3:06 AM, Berg, Michael C wrote:
> Hi Folks,
>
> I would like to contribute AVX 512 changes for bug fixes and 
> performance issues. I need two reviewers to examine this patch and comment as needed:
>
> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779
>
> webrev:
>
> http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/
>
> Debugging on Evex machines, a number of issues were uncovered which 
> could not be addressed via emulation. These changes include a unified 
> approach with call frames for Evex and pre Evex targets, performance 
> changes for 32 bit Evex performance, general improvements to all x86 
> targets for reduction patterns, encoding changes for correctness, 
> changes that reduce register pressure for generated code, CPUID 
> additions for additional state control, vector length guards on 
> instructions which only partially support Evex on some targets. Also 
> included are the addition of a state object which is atomic to each 
> instruction emit and which is programmed with specific target 
> information. There is a reduction of x86 assembler interfaces from 20 
> to 4. Code which manages the legacy code path for instructions which 
> do not have Evex support is also included which must manage upper bank 
> resources of registers while avoiding complication in the register 
> allocator which would bloat code.
>
> Please consider this a high priority review for target system usage.
>
> Thanks,
>
> Michael
>


More information about the hotspot-compiler-dev mailing list