RFR(L): 8031321 Support Intel bit manipulation instructions

[Igor Veresov]

Can I please get a second review for this?

http://cr.openjdk.java.net/~iveresov/8031321/webrev.04/

igor

On Feb 11, 2014, at 2:19 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> 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
>>>>>>> 
>>>>> 
>>> 
>>