CR for RFR 8165565

[Vladimir Kozlov]

Looks good.

Thanks,
Vladimir

On 9/7/16 11:04 AM, Berg, Michael C wrote:
> Vladimir please see the latest webrev:
>
> http://cr.openjdk.java.net/~mcberg/8165565/webrev.02a/
>
> It has the change for check_branch_variant.
> I have tested it out and it works as advertised.
>
> Regards,
> Michael
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Wednesday, September 07, 2016 10:10 AM
> To: Berg, Michael C <michael.c.berg at intel.com>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: CR for RFR 8165565
>
> Michael, I think you should instead modify first condition in
> InstructForm::check_branch_variant()
>
> Thanks,
> Vladimir
>
> On 9/7/16 9:57 AM, Berg, Michael C wrote:
>> Hi Folks,
>>
>> Some cases of CountedLoopEnd have side effect code on targets like SKX
>> for vector processed post loops that are unsafe to translate to short
>> branch versions. A recent change between b126 and b127 exposes this
>> problem. The simple solution is to not allow short branch mapping for
>> these cases. This produces correct code. A patch will be uploaded
>> shortly to exemplify this case. The failures show up in SPECjvm2008 in
>> the scimark metrics after b127 inclusive for SKX targets.
>>
>>
>>
>> This code was tested as follows: hotspot jreg, SPECjvm2008 on bdw and
>> skx complete with no issues.
>>
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8165565
>>
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~mcberg/8165565/webrev.01/
>>
>>
>>
>> Essentially it preserves this ad file pattern on x86 by disallowing
>> branch shortening (this instruction pattern is predicate guarded for
>> skx like platforms):
>>
>>
>>
>> jmpLoopEnd_and_restoreMask() {
>>   match(CountedLoopEnd cop cr);
>>     __ jcc((Assembler::Condition)($cop$$cmpcode), *L, false);
>>     __ restorevectmask();
>>
>>
>>
>> which has the restore vector mask side effect code.
>>
>>
>>
>> Regards,
>>
>> Michael
>>