RFR(L): 8031321 Support Intel bit manipulation instructions

[Igor Veresov]

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