RFR(L): 8031321 Support Intel bit manipulation instructions

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 2/11/14 1:37 PM, Igor Veresov wrote:
> I’ve noticed a problem with the command line flags validation, so here’s the changed webrev:
>
> http://cr.openjdk.java.net/~iveresov/8031321/webrev.04/
>
> The changes are only in vm_version_x86.cpp in flags processing. -XX:-UseBMI1Instructions now turns off UseCountTrailingZerosInstruction as well, because it’s a part of the BMI1 (unless it is separately set). Also added missing validation for lzcnt and tzcnt support in case the flags are set by the user.
>
> igor
>
> On Feb 10, 2014, at 1:25 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>
>> OK, I’ve put in the exceptions: http://cr.openjdk.java.net/~iveresov/8031321/webrev.03/
>>
>> igor
>>
>>
>> On Feb 10, 2014, at 2:17 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>>> Igor,
>>>
>>>> No, since it just pattern-matches most of them there is not. One approach would be to do -XX:+PrintOptoAssembly and then analyze the output (that’s how I basically did it). If you want to automate it then may be you can just  "grep | wc -l" the assembly output for the instructions that should be there.
>>> It makes me a sad panda. is it possible that someday we will have a diagnostic flag for pattern-matches?
>>>
>>>> 106   private static void fail() {
>>>> 107     System.out.println("FAILED");
>>>> 108     System.exit(97);
>>>> 109   }
>>> Could you please don't use System.exit, it's against jtreg's best practice[*]? You should throw an exception instead. I'd prefer the exception w/ a test name in a description, something like this:
>>>> 120     { // match(Set dst (AndI (XorI src1 minus_1) src2))
>>>> 121       int z = BMITests.andnl(ix, iy);
>>>> 122       for (int i = 0; i < ITERATIONS; i++) {
>>>> 123         int ii = BMITests.andnl(ix, iy);
>>>> 124         if (ii != z) {
>>>> 125           throw new Error("BMITests.andnl failed");
>>>> 126         }
>>>> 127       }
>>>> 128     }
>>> ...
>>>> 295     {
>>>> 296       int z = BMITests.tzcntq(lx);
>>>> 297       for (int i = 0; i < ITERATIONS; i++) {
>>>> 298         int ii = BMITests.tzcntq(lx);
>>>> 299         if (ii != z) {
>>>> 300           throw new Error("BMITests.tzcntq failed");
>>>> 301         }
>>>> 302       }
>>>> 303     }
>>>
>>> [*] http://openjdk.java.net/jtreg/faq.html#question2.6
>>>
>>> Thanks
>>> Igor
>>>
>>> Igor
>>>
>>> On 02/09/2014 02:55 AM, Igor Veresov wrote:
>>>> No, since it just pattern-matches most of them there is not. One approach would be to do -XX:+PrintOptoAssembly and then analyze the output (that’s how I basically did it). If you want to automate it then may be you can just  "grep | wc -l" the assembly output for the instructions that should be there.
>>>>
>>>> igor
>>>>
>>>> On Feb 8, 2014, at 2:19 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>
>>>>> Igor,
>>>>> Are there any diagnostic flags which allow to verify that these instructions were used, like PrintIntrinsics?
>>>>>
>>>>> Igor
>>>>>
>>>>> On 02/07/2014 02:10 AM, Igor Veresov wrote:
>>>>>> This change adds support for BMI1 instructions on x86 (supported on AMD Piledriver and Intel Haswell).
>>>>>> The changes in the matcher.cpp are kind of a temporary hack to workaround the inability to describe DAGs in ADL. I’ll address that problem properly a bit later (we need this change to land in 8u20).
>>>>>>
>>>>>> I’m also using Rickard’s changes in type.hpp that are not quite in the repo yet.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8031321/webrev.00/
>>>>>>
>>>>>> Testing: jprt, jtreg, ctw, the new regtest (verified that the instructions are generated and all).
>>>>>>
>>>>>> igor
>>>>>>
>>>>
>>
>