Fixing enums on big-endian systems

[Joe_Groff]

@mundaym

To fix the core issue I think we need to strictly define the spare bit vector (whether represented as a SpareBitVector , directly as a ClusteredBitVector or as an APInt ) as a little-endian integer representation of the memory layout. This means that on big-endian systems we'll need to byte swap 'chunks' when adding to - and reading from - the spare bit vectors, probably making use of helper functions or maybe methods on SpareBitVector` (if possible without ending up with circular dependencies).

Yeah, this was always the intent, that the compiler representations be strictly little-endian-bit-order, though we at Apple didn't have time or immediate need to handle the big-endian cases, alas. There is some cleanup in this area that I think would be good to do. There's no good reason to use both ClusteredBitVector and APInt together; it'd be good to standardize on APInt, which is the more fleshed-out and capable interface from LLVM. There are also some slightly higher-level abstractions you can work with that should hopefully make the task easier; EnumPayload in particular is intended to be the primary interface for working with enum payloads as LLVM values. Its interface provides mechanisms for initializing constant values from an APInt, as well as application of constant APInt masks and so on. The implementation handles "chunking" the abstract little-endian bit vector into word-sized components that LLVM can handle. Hopefully, most of your job dealing with endianness can be concentrated in the EnumPayload interface, doing the necessary transformation during chunking and unchunking into LLVM values. EnumPayload itself also incompletely adopted, though, and it would be good cleanup to make it used more pervasively, which would hopefully also reduce the amount of endian-specific code you all have to deal with.