[llvm-dev] Global ISel match table

[Daniel Sanders via llvm-dev]

Looking through the commands, AFAICT going to uint32_t should be safe except for GIM_CheckLiteralInt, GIR_AddImm which will need some changes to store their 64-bit immediates as two 32-bit halves.

For testing, making sure llvm-lit and test-suite don't change behaviour will be the main one but there's a couple other things that can make you fairly confident without that:
Continue using uint64_t in TableGen and convert to 32-bit at the last moment. Then assert that there was no loss of information in the cast
Diff the state machine table before and after. Labels and JumpTargets aside it should be almost identical with just the changes to GIM_CheckLiteralInt  GIR_AddImm. The Labels and JumpTargets will be thrown out by the extra elements but it's possible to script the corrections to end up with matching tables. For example, in vim I'd probably use macros to find and increment all the Labels/JumpTargets following a GIM_CheckLiteralInt/GIR_AddImm

> On Dec 16, 2020, at 06:50, Paul C. Anagnostopoulos <paul at windfall.com> wrote:
> 
> Indeed, this is certainly a complication. If we go to uint32_t, then we could use table indexes for those commands, correct? Surely no table will ever have more than 4 billion entries.
> 
> In anticipation of working on this, can you tell me what is the easiest way to test such changes? I haven't gotten my head around the testing procedures yet.
> 
> 
> At 12/15/2020 10:44 PM, Daniel Sanders wrote:
>> Most of the reasons boil down to not having the time needed to implement something better. There is one bit I'm aware of that snowballs a bit when using uint32_t or smaller. Labels and JumpTargets are currently absolute which allows them to be recorded in a simple lookup table during the first pass to encode on the second. JumpTargets will need to become relative (and know where they are in the table) to cope with a large ruleset and reduced range but that also means you have to start measuring distances between two points in the table. For fixed-sized commands that's not too bad but if the range drops below the minimum then you also have to go to variable length commands (or waste space on padding). That in turn means that you need to determine the encoded size of commands on the first pass (including JumpTargets which have unknown encoding until the label is seen later) so that the labels know their position for the second pass when we encode the table. We'll have to go from the two-pass approach to a relaxation one.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201216/1e6bed28/attachment.html>