[llvm-dev] [cfe-dev] [RFC] Loading Bitfields with Smallest Needed Types (original) (raw)

Richard Smith via llvm-dev llvm-dev at lists.llvm.org
Fri May 29 16:00:22 PDT 2020

On Fri, 29 May 2020 at 11:06, John McCall via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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?

I don't think this has anything to do with bit-fields or Clang's lowering. This seems to "just" be an optimizer issue (one that happens to show up for bit-field access patterns, but also affects other cases). Much-reduced testcase:

unsigned short n; void set() { n |= 1; }

For this testcase, -O2 generates a 1-byte 'or' instruction, which will often be a pessimization <http://quick-bench.com/e61y0Wn1qR-9K1YM6Bf9YoS6qfY> when there are also full-width accesses. I don't think the frontend can or should be working around this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200529/12d28121/attachment.html>

More information about the llvm-dev mailing list