RFR (S) : 8014362 : Need to expose some processor features via Unsafe interface
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu May 16 15:57:44 PDT 2013
X86_ONLY() is ugly. I would prefer to have something similar to
VM_Version::has_fast_idiv(): VM_Version::has_clmul(). The drawback is
you have to define it on all platforms. Which may be not bad if some of
them have similar feature.
This is an other reason I don't like your approach of using x86 specific
code in libraries. What if arm64 will have instructions to optimize crc?
Vladimir
On 5/16/13 3:25 PM, David Chase wrote:
>
> On 2013-05-16, at 6:16 PM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On May 16, 2013, at 2:56 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>
>>> Hmm. Tao spent a lot of time to move all processor specific flags into the respective globals_<arch>.hpp file. I don't think we should undo this.
>>
>> I agree. That opens the question of how to manage the PUTPROP call in shared code (jvm.cpp).
>>
>> David, as a least-bad solution, I suggest protecting the x86-specific names in jvm.cpp with X86_ONLY:
>>
>> + X86_ONLY(PUTPROP(props, "sun.zip.clmulSupported", UseAVX && UseCLMUL ? "true" : "false"));
>>
>> or:
>>
>> + PUTPROP(props, "sun.zip.clmulSupported", X86_ONLY(UseAVX && UseCLMUL ||) false ? "true" : "false"));
>>
>> or:
>>
>> + PUTPROP(props, "sun.zip.clmulSupported", X86_ONLY(UseAVX && UseCLMUL ? "true" :) "false"));
>>
>> —
>
> That seems entirely reasonable, and allows me to move CLMUL into the x86 file. I wasn't sure what our attitude was towards #ifdefs in that code. I'll try to have a new webrev up soon.
>
> David
>
More information about the hotspot-compiler-dev
mailing list