[cfe-dev] [llvm-dev] [RFC] Loading Bitfields with Smallest Needed Types

[John McCall via cfe-dev]

On 28 May 2020, at 18:42, Bill Wendling wrote:

> On Tue, May 26, 2020 at 7:49 PM James Y Knight via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> At least in this test-case, the "bitfield" part of this seems to be a 
>> distraction. As Eli notes, Clang has lowered the function to LLVM IR 
>> containing consistent i16 operations. Despite that being a different 
>> choice from GCC, it should still be correct and consistent.
>>
> I suspect that this is more prevalent with bitfields as they're more
> likely to have the load / bitwise op / store operations done on them,
> resulting in an access type that can be shortened. But yes, it's not
> specific to just bitfields.
>
> I'm more interested in consistency, to be honest. If the loads and
> stores for the bitfields (or other such shorten-able objects) were the
> same, then we wouldn't run into the store-to-load forwarding issue on
> x86 (I don't know about other platforms, but suspect that consistency
> wouldn't hurt). I liked Arthur's idea of accessing the object using
> the type size the bitfield was defined with (i8, i16, i256). It would
> help with improving the heuristic. The downside is that it could lead
> to un-optimal code, but that's the situation we have now, so...

Okay, but what concretely are you suggesting here?  Clang IRGen is
emitting accesses with consistent sizes, and LLVM is making them
inconsistent.  Are you just asking Clang to emit smaller accesses
in the hope that LLVM won’t mess them up?

John.