[llvm-dev] endianness and bit fields in struct{}

[Tim Northover via llvm-dev]

Hi Dmitry,

On 1 June 2018 at 08:01, Dmitry Ponyatov via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Is any work in the LLVM development community are pointed to expanding IR
> model to support bit fields and arbitrary endianness manipulations?

Not as far as I'm aware. If anything the reverse is happening and
we're simplifying the type system. We once had union types but they
were removed years ago due to bitrotting, and there's an ongoing
effort to move to just a single pointer type.

> Looking on code generated by clang, it looks like LLVM IR not only has no support for endianness attributes

Yes, this would be handled by the @llvm.bswap.* intrinsics, which can
be trivially folded into loads & stores if instructions are available.
LLVM IR is a load/store architecture and endianness attributes really
don't justify themselves in that regime.

> As an example, generated IR uses in-compiled and/or bitmasking should be replaced with special bit-fields operations with ui3, si7 arbitrary length integers.

We certainly *could* do that, but IMO the motivation is pretty weak there too.

Firstly, backends tend to produce better code for natively sized
types, or powers of 2 at the worst. Others should work, but they're
not what anyone optimizes for (which leads to a bit of a vicious
circle where front-ends avoid using them, for better or worse).

Also, the existing instructions really do represent what most CPUs are
going to do to manipulate bitfields. Hiding that behind special
instructions just means they're going to be expanded later and
complicates the cost-models on average. Targets that do have special
bitfield instructions (AArch64 for example) can pattern-match those
manipulations without too much difficulty to make use of them.

Cheers.

Tim.