[PATCH] Change MachineOperand OpKind to a bitfield

[Rafael Espíndola]

Thanks.

We probably shouldn't block improving clang on the potential for optimizing
the existing code.

How about committing you patch and opening bugs on llvm and clang?
On Apr 20, 2015 8:36 PM, "Pete Cooper" <peter_cooper at apple.com> wrote:

>
> > On Apr 20, 2015, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote:
> >
> >
> >> On Apr 20, 2015, at 4:10 PM, 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 don't know the actual clang code, but isn't the canonical codegen for
> something like the following "unsigned SubReg_TargetFlags : 12;" to load an
> "unsigned" value and shift/mask that? Why does it use i24?
> Attached code to demonstrate this.  Here’s a reduced version of
> MachineOperand compiled with and without the change.
>
> To answer your question, clang has decided that the 24 bits total of
> bitfields should be represented as a [3 x i8].  So to read one of the
> bitfields, it casts the [3 x i8]* to i24* then does a load.  I guess it
> just wants to always load and store the whole bitfield when operating on
> any one piece of it.
>
> I’m not sure if this is a requirement of C++ or not.  Personally, i’d like
> clang to use powers of 2 which are a multiple of 8 (i.e., 8, 16, 32, 64)
> for bitfield operations in the IR, but i don’t know if it can or not.
>
> Pete
>
>
>
> >
> > - Matthias
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150422/3bdd4941/attachment.html>