>            Summary: movsww (%ecx),%ax x86->IR: unhandled instruction bytes:
>                     0x66 0xF 0xBF 0x1


Are you sure this is a valid instruction?

0F BF would be 'movswl r/m16, r32'.  So I can only imagine that
66 0F BF would mean 'movsww r/m16, r16'; which is a simple 16-bit
move.  In which case why not just use a normal move instruction.

Can you find the instruction in the liboil sources?  It would help
to know what the liboil authors intended to happen.

gdb says it is movsww (%ecx),%ax:

(gdb) x/4xb 0
0x0:    0x66    0x0f    0xbf    0x01
(gdb) x/i 0
0x0:    movsww (%ecx),%ax

Apparently version 0.3.8 of liboil used it, but then later it was replaced and doesn't seem to be the same in 0.3.10:

-      "1:  movsxw (%1), %%eax           \n"
+      "1:  movswl (%1), %%eax           \n"

Here's the commit:

revision 1.2
date: 2006-05-23 01:50:46 +0200;  author: ds;  state: Exp;  lines: +1 -1
* liboil/i386/abs_i386.c:
* liboil/i386/error8x8_i386.c:
Change movsx opcodes to something more AT&T-like.

We'd have to ask Dave Schleef for the exact history, but I suspect that the function in question (for performing ABS() on 16 bit ints) was autogenerated by the 'uberopt' code optimiser.

abs_u16_s16_i386asm3 is the function in liboil that had the instruction.

*** Bug 250799 has been marked as a duplicate of this bug. ***

Fixed, vex r2056.