RFR(L): 8031321 Support Intel bit manipulation instructions (original) (raw)

Igor Ignatyev igor.ignatyev at oracle.com
Mon Feb 10 02:17:15 PST 2014

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

More information about the hotspot-compiler-dev mailing list