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

[Richard Smith via llvm-dev]

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>