[PATCH] Change MachineOperand OpKind to a bitfield

[Rafael Espíndola]

Chandler did some work on this area.

If I remember correctly the idea is that clang should use the widest
load/store possible and llvm should try to codegen it to narrower
instructions when profitable.

Chandler, do you know if this is a case where clang could produce an
i32 load or llvm could do a better job with i8 and i16 loads?



On 20 April 2015 at 19:10, Pete Cooper <peter_cooper at apple.com> wrote:
> Hi Rafael
>
> MachineOperand::OpKind is an unsigned char, followed by 24-bits of bitfields.  clang is able to make all of that take 32-bits of space, but it generates pretty nasty code to do so.
>
> OpKind itself is loaded and stored as an i8 and so gets very nice IR.  However, loading an entry from one of the bitfields results in a load of an i24, then masking operations.  Given that i24 isn’t legal, the legalizer goes to great lengths to make this work, typically splitting it in to i8 and i16 operations.
>
> I’m not sure if clang is allowed to fold the bitfield operations in to OpKind and do everything as i32 (what if OpKind was volatile for example).  So instead here’s a patch to change OpKind to an i8.  I’m also not sure if llvm’s optimizer could be taught this, although thats some pretty scary code to have to write.
>
> I’ve verified that this generates i32 load/store for all reads/writes of all the fields.  So OpKind itself results in a small increase in code size to be read (an i32 load followed by a trunc, usually folded away in ISel), but the reads of the other fields are much better.
>
> Overall this saves 16KB on the size of the llc binary.
>
> Cheers,
> Pete
>