CR for RFR 8165565

[Berg, Michael C]

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
>