CR for RFR 8140779

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


Sure thing Vladimir.  All the issues we found were resolved with the last webrev.
The one below was one that needed a change for avx1.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Monday, November 09, 2015 9:16 PM
To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net
Subject: Re: CR for RFR 8140779

I saw that Igor pushed these changes today. But I did not saw final RFR on this mailing list.
The last thing I saw in private mail was .ad problems reported by Igor:

1. Some failures with specjvm98 and scimark while matching AbsD
o529	AbsD	=== _ o525  [[o531 ]]

...

What was the problem?

Michael, can you publish latest webrev in this open mailing thread for history?

Thanks,
Vladimir

On 10/30/15 10:47 PM, Vladimir Kozlov wrote:
>  > match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector().
>
> This change was done only in x64 .ad files. It should be done in other platforms too.
>
> Igor or who will sponsor this, please, make corresponding changes in 
> our closed sources too (in .ad file and c2_globals_*.hpp).
>
> Thanks,
> Vladimir
>
> On 10/31/15 12:06 PM, Berg, Michael C wrote:
>> 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