[RFC] Extend Machine Value Type from `uint8_t` to `uint16_t`

LLVM Project
1

Overview and Problem statement

Currently 208 out of 256 MVTs are used, as some current patches are adding more MVTs, it will be run out soon, so ultimately we need to extend the original MVT::SimpleValueType from uint8_t to uint16_t to accommodate more types.

Measurement

The MatcherTable uses unsigned char for encoding the matcher code, so the extended MVTs are no longer fit into the table, thus we need to use VBR to encode them as we do on others that are wider than 8 bits.

The statistics below shows the difference of “Total Array size” of the matcher table that appears in every files:

Table                       Before     After     Change(%)
WebAssemblyGenDAGISel.inc   23576      23775     0.844
NVPTXGenDAGISel.inc         173498     173498    0
RISCVGenDAGISel.inc         2179121    2369929   8.756
AVRGenDAGISel.inc           2754       2754      0
PPCGenDAGISel.inc           163315     163617    0.185
MipsGenDAGISel.inc          47280      47447     0.353
SystemZGenDAGISel.inc       56243      56461     0.388
AArch64GenDAGISel.inc       467893     487830    4.261
MSP430GenDAGISel.inc        8069       8069      0
LoongArchGenDAGISel.inc     78928      79131     0.257
XCoreGenDAGISel.inc         3432       3432      0
BPFGenDAGISel.inc           3733       3733      0
VEGenDAGISel.inc            65174      66456     1.967
LanaiGenDAGISel.inc         2067       2067      0
X86GenDAGISel.inc           628787     636987    1.304
ARMGenDAGISel.inc           170968     171036    0.040
HexagonGenDAGISel.inc       155764     155764    0
SparcGenDAGISel.inc         5762       5798      0.625
AMDGPUGenDAGISel.inc        504356     504463    0.021
R600GenDAGISel.inc          29785      29785     0

The statistics below shows the runtime peak memory usage by compiling a
simple C program:
/bin/time -v clang -target $TARGET -O3 -c test.c

  int test(int a) {
    return a * 3;
  }

Target        Before(kbytes)    After(kbytes)    Change(%)
wasm64        110172            110088           -0.076
nvptx64       109784            109980            0.179
riscv64       114020            113656           -0.319
avr           110352            110068           -0.257
ppc64         112612            112476           -0.120
mips64        113588            113668            0.070
systemz       110860            110760           -0.090
aarch64       113704            113432           -0.239
msp430        110284            110200           -0.076
loongarch64   111052            110756           -0.267
xcore         108340            108020           -0.295
bpf           110620            110708            0.080
ve            110960            110920           -0.036
lanai         110180            109960           -0.200
x86_64        113640            113304           -0.296
arm64         113540            113172           -0.324
hexagon       114620            114684            0.056
sparc         110412            110136           -0.250
amdgcn        118164            117144           -0.863
r600          111200            110508           -0.622

Pull requests

CC: @wangpc-pp @jayfoad @topperc @kito-cheng

1 Like
2

Can you please measure the performance impact with https://llvm-compile-time-tracker.com/ ?

4

Here you are: LLVM Compile-Time Tracker

5

Hi @songwu0813,

As far as I’m concerned, this sounds reasonable and the impact is IMHO acceptable.

We may want to reorder the MVT based on some profiling information like Pengcheng said at:

Cheers,
-Quentin

1 Like
6

Correct, I’ll collect the data after the patch merged, thanks!