[00/11] x86: disassembler size reduction and fixes

Message ID bcddcee7-dee5-3095-d2dd-e78b72d040c2@suse.com
Headers show
Series
  • x86: disassembler size reduction and fixes
Related show

Message

Jan Beulich July 3, 2020, 1:46 p.m.
Over time I've run into many redundancies in the disassembler tables.
This series tries to take care of some of them, and then addresses
issues noticed along the road. FAOD I'm not inclined to add testsuite
coverage for the "mistakenly disassembles invalid encoding" kind of
issues fixed here - the patterns to check for are just too ugly, and
too likely to need changing (perhaps even for entirely unrelated
changes). In my own disassembler library I have chosen to decode e.g.
(Intel syntax, be aware)

	C5FAFFC0            	VEX.128.F3.0F:FF R0, R0, R0
	62F17C0FFFC0        	EVEX.128.0F.W0:FF R0{k7}, R0, R0

which I think is far more reasonable than

 +[a-f0-9]+:	c5 ac 46 f5          	kxnorw %k5,\(bad\),%k6

or

[ 	]*[a-f0-9]+:	62                   	vpmovdb %zmm6,\(bad\)
[ 	]*[a-f0-9]+:	f2 7e 58             	bnd jle (0x7d|7d <.text\+0x7d>)
[ 	]*[a-f0-9]+:	31 72 7f             	xor    %esi,0x7f\(%edx\)

or

[ 	]*[a-f0-9]+:	c5 fa 28             	\(bad\) *
[ 	]*[a-f0-9]+:	ff cc                	dec    %esp
[ 	]*[a-f0-9]+:	c4 e1 7b 28          	\(bad\) *
[ 	]*[a-f0-9]+:	ff cc                	dec    %esp
[ 	]*[a-f0-9]+:	62 f1 fc 08 28       	\(bad\) *
[ 	]*[a-f0-9]+:	ff cc                	dec    %esp

It would only be at such a time, when sensible (and, by as good as
predictions can be, stable) patterns could be checked for, that I'd
be willing to add coverage for issues found. Note that e.g. there's
not even a consistent pattern of how many opcode bytes would be
printed ahead of a "(bad)".

Fundamentally of course such tests should have been put in place at
the time support for these insns was added, which would then have
avoided the bugs in the first place.

01: replace EX{d,q}Scalar by EXxmm_m{d,q}
02: replace EXqScalarS by EXqVexScalarS
03: drop EVEX table entries that can be served by VEX ones
04: honor VEX.W for VCVT{PH2PS,PS2PH}
05: AVX512 extract/insert insns need to honor EVEX.L'L
06: AVX512 VPERM{D,Q,PS,PD} insns need to honor EVEX.L'L
07: drop EVEX table entries that can be made served by VEX ones
08: adjust/correct V*{F,I}{32x8,64x4}
09: most VBROADCAST{F,I}{32,64}x* only accept memory operands
10: use %LW / %XW instead of going through vex_w_table[]
11: adjust/correct VFRCZ{P,S}{S,D} decoding

Jan

Comments

Alan Modra via Binutils July 3, 2020, 2:25 p.m. | #1
On Fri, Jul 3, 2020 at 6:46 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> Over time I've run into many redundancies in the disassembler tables.

> This series tries to take care of some of them, and then addresses

> issues noticed along the road. FAOD I'm not inclined to add testsuite

> coverage for the "mistakenly disassembles invalid encoding" kind of

> issues fixed here - the patterns to check for are just too ugly, and

> too likely to need changing (perhaps even for entirely unrelated

> changes). In my own disassembler library I have chosen to decode e.g.

> (Intel syntax, be aware)

>

>         C5FAFFC0                VEX.128.F3.0F:FF R0, R0, R0

>         62F17C0FFFC0            EVEX.128.0F.W0:FF R0{k7}, R0, R0

>

> which I think is far more reasonable than

>

>  +[a-f0-9]+:    c5 ac 46 f5             kxnorw %k5,\(bad\),%k6

>

> or

>

> [       ]*[a-f0-9]+:    62                      vpmovdb %zmm6,\(bad\)

> [       ]*[a-f0-9]+:    f2 7e 58                bnd jle (0x7d|7d <.text\+0x7d>)

> [       ]*[a-f0-9]+:    31 72 7f                xor    %esi,0x7f\(%edx\)

>

> or

>

> [       ]*[a-f0-9]+:    c5 fa 28                \(bad\) *

> [       ]*[a-f0-9]+:    ff cc                   dec    %esp

> [       ]*[a-f0-9]+:    c4 e1 7b 28             \(bad\) *

> [       ]*[a-f0-9]+:    ff cc                   dec    %esp

> [       ]*[a-f0-9]+:    62 f1 fc 08 28          \(bad\) *

> [       ]*[a-f0-9]+:    ff cc                   dec    %esp

>

> It would only be at such a time, when sensible (and, by as good as

> predictions can be, stable) patterns could be checked for, that I'd

> be willing to add coverage for issues found. Note that e.g. there's

> not even a consistent pattern of how many opcode bytes would be

> printed ahead of a "(bad)".

>

> Fundamentally of course such tests should have been put in place at

> the time support for these insns was added, which would then have

> avoided the bugs in the first place.

>

> 01: replace EX{d,q}Scalar by EXxmm_m{d,q}

> 02: replace EXqScalarS by EXqVexScalarS

> 03: drop EVEX table entries that can be served by VEX ones

> 04: honor VEX.W for VCVT{PH2PS,PS2PH}

> 05: AVX512 extract/insert insns need to honor EVEX.L'L

> 06: AVX512 VPERM{D,Q,PS,PD} insns need to honor EVEX.L'L

> 07: drop EVEX table entries that can be made served by VEX ones

> 08: adjust/correct V*{F,I}{32x8,64x4}

> 09: most VBROADCAST{F,I}{32,64}x* only accept memory operands

> 10: use %LW / %XW instead of going through vex_w_table[]

> 11: adjust/correct VFRCZ{P,S}{S,D} decoding

>


OK.

Thanks.

-- 
H.J.