This is WIP and it is motivated by the suggestions in http://lists.llvm.org/pipermail/cfe-dev/2018-June/058263.html
First attempt, piggybacking the extend information in a structure where the bit-width of the integer represents the exact extension intended. There is a bit of overlapping with the original Extend but I'm not convinced we win anything from rewriting it into the new representation.
I plan to test this using unit tests but I can link a diff with the current usage in case it helps.
Hmm. I understand the need to use something uniqued here, but I think it would probably be more natural to at least use a llvm::ConstantDataArray (which could be null if there are no interesting bits) instead of encoding the information into the types of a struct type. That would also make it easy to generalize the elements to an arbitrary flags type.
Also, on 64-bit targets this will increase the size of an ABIArgInfo to four pointers from three. That's fine to the extent that we work with independent ABIArgInfos, but I'm getting a little annoyed at the storage overhead of the array of ABIArgInfos in CGFunctionInfo given that, in the overwhelmingly common case, an ABIArgInfo is no more than a kind and maybe a few of these flags. Maybe there's some reasonable way to optimize the storage of an ABIArgInfo in a CGFunctionInfo so that we only need the extra storage in less-common cases? Like extracting out a base class that's the Kind+Flags and making the main array be an array of those + an optional index into a second trailing array of full ABIArgInfos.
I might be overthinking this, though.