CR for RFR 8140779

[Vladimir Kozlov]

Thank you, Michael.

For the records, this was reviewed and pushed into hs-comp.

Thanks,
Vladimir

On 11/10/15 9:39 AM, Berg, Michael C wrote:
> 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
>>