[RFC] Support reg sizes greater than 65534

LLVM Project
1

Hi LLVM folks,

A private ISA that I work on deals with 65536-bits registers, which exceeds current allowed max register size UINT16_MAX - 1 (i.e. 65535 - 1; 65535 is treated as a special value).

I changed the codebase to use uint16_t instead of uint32_t, e.g. for MCRegisterClass::RegSizeInBits. My implementation could be found here. I wonder what does the community think about merging this into the upstream? I did some simple performance measurement on Release build and did not observe regressions:

Test command:

$ cmake ../llvm -DCMAKE_BUILD_TYPE=Release -G Ninja
$ ninja -j 20
$ ninja -j 20 check-all

Before (tested on 22ef7ba), avg = 143.87s:

Run #1: 141.23s
Run #2: 143.22s
Run #3: 143.28s
Run #4: 144.73s
Run #5: 146.88s

After, avg = 142.79s:

Run #1: 139.14s
Run #2: 140.43s
Run #3: 141.63s
Run #4: 149.73s
Run #5: 143.01s

Thanks,
Chenguang

2

I would suggest running this through the LLVM Compile-Time Tracker. Also, do any static data tables in the compiler get significantly larger? Or is there any measurable impact on compiler memory usage?

3

Hi @jayfoad,

Regarding performance, I think in this case it’s more about the increased memory usage, and how often cache misses and swapping are triggered. So, going back to the commit, it affects:

TargetRegisterInfo::SubRegCoveredBits, 4 bytes → 8 bytes

This only affects the TargetRegisterInfo::SubRegCoveredBits XXXSubRegIdxRangeTable[] array in XXXGenRegisterInfoTargetDesc.inc. The array is pretty short:

  • X86: 33 entries (+132 bytes)
  • AArch64: 144 entries (+576 bytes)
  • RISC-V: 116 entries (+464 bytes)

MCRegisterClass, 32 bytes → 40 bytes

Similarly, this only affects the MCRegisterClass XXXMCRegisterClasses[] in XXXGenRegisterInfoMCDesc.inc:

  • X86: 135 entries (+1080 bytes)
  • AArch64: 528 entries (+4224 bytes)
  • RISC-V: 152 entries (+1216 bytes)

TableGen InfoByHwMode.h SubRegRange, 4 bytes → 8 bytes

This is only used by TableGen backends.

It seems like the performance impact should be negligible. Also, from the compiler time tracker website:

If you… regularly does compile-time sensitive work and would like to test the compile-time impact of your patches before they land, contact me at…

Since I don’t “regularly do compile-time sensitive work”, maybe we could just do a post-submit performance analysis instead?

4

In the past, around six months ago, we had some changes that increased the size of the TableGen-generated files and ended up blowing memory on some BBs. So we definitely need to be careful here.

5

I’ve pushed your branch to perf/reg_u32 in my fork so it should show up here soon:

2 Likes
6

Thanks @jayfoad! The results are out; seems like the impact indeed is minimal. :slight_smile:

1 Like
7

Opened PR #201886.