RFR(L): 8031321 Support Intel bit manipulation instructions (original) (raw)
Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Feb 11 14:19:19 PST 2014
- Previous message: RFR(L): 8031321 Support Intel bit manipulation instructions
- Next message: RFR(L): 8031321 Support Intel bit manipulation instructions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 vmversionx86.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 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
- Previous message: RFR(L): 8031321 Support Intel bit manipulation instructions
- Next message: RFR(L): 8031321 Support Intel bit manipulation instructions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the hotspot-compiler-dev mailing list