Summary: | vex x86->IR: unhandled instruction bytes: 0xF3 0xF 0xBC (tzcnt) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Viraj Kanwade <bugs.kde.org> |
Component: | vex | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | jakub, tom |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Viraj Kanwade
2012-06-01 19:21:55 UTC
That's a TZCNT instruction, but I'm a bit surprised to see it in an Intel CPU as I thought it was an AMD specific instruction. It's listed in the Opcode map in the Intel manual but not in the main instruction reference... See also bug #295808 for this same instruction in 64 bit mode. https://bugs.kde.org/show_bug.cgi?id=295808#c8 should fix this. LZCNT and TZCNT are part of LZCNT resp. BMI1 ISA extensions, documented in both the AMD manuals and in http://software.intel.com/file/45207 - 319433-013b.pdf - I think it wasn't in the earlier 319433-011.pdf yet. The reason why GCC uses TZCNT now unconditionally is that for the non-zero values where the BSF insn is actually defined, TZCNT, REP; BSF and BSF give actually the same results (appart from different flags), so it doesn't matter which one is used and when tuning for future CPUs TZCNT is a better choice. Unlike this, LZCNT gives different values (operand size - 1 - BSR), so LZCNT is going to appear usually just in code targetted at CPUs with the LZCNT ISA extension. |