RFR(M) 8152496: Blended code generation
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Mar 25 22:48:34 UTC 2016
Looks good to me.
Thanks,
Vladimir
On 3/25/16 11:44 AM, Berg, Michael C wrote:
> Here is the webrev with the changes from below.
>
> http://cr.openjdk.java.net/~mcberg/8152496/webrev.02/
>
> Thanks,
> Michael
>
> -----Original Message-----
> From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com]
> Sent: Thursday, March 24, 2016 11:32 AM
> To: Christian Thalinger <christian.thalinger at oracle.com>; Berg, Michael C <michael.c.berg at intel.com>
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(M) 8152496: Blended code generation
>
> On 03/24/2016 08:55 PM, Christian Thalinger wrote:
>>> On Mar 24, 2016, at 7:50 AM, Berg, Michael C
>>> <michael.c.berg at intel.com <mailto:michael.c.berg at intel.com>> wrote:
>>>
>>> Hi All,
>>>
>>> I would like to contribute blended code generation. On EVEX enabled
>>> platforms that have sufficient CPUID support, it is a boon to mix
>>> code generation to keep size manageable when emitting EVEX code, we
>>> can migrate compatible versions to AVX when resources allow, this
>>> enables an uplift of as much as 12% on known metrics such as those in
>>> SpecJvm2008. Reportable score uplift on a base run is enhanced
>>> nominally by 6%.
>>> These changes uplift performance via 64-bit and 32-bit code
>>> generation generically wherever scalar or vector SIMD is present.
>
> Oh wow.
>
>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8152496
>>> webrev:
>>> http://cr.openjdk.java.net/~mcberg/8152496/webrev.01/
>>> <http://cr.openjdk.java.net/%7Emcberg/8152496/webrev.01/>
>
> This is suspicious, should be 0x79?
> 6187 emit_int8(79)
>
> Only x86_32.ad changes, no x86_64.ad?
>
> is_managed is cryptic, and probably deserves a comment.
>
> Thanks,
> -Aleksey
>
More information about the hotspot-compiler-dev
mailing list