<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 4, 2017 at 1:57 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <p>Nevertheless, I think that you've convinced me that this is a
    least-bad solution. I'll want a flag preserving the old behavior.
    Something like -fwiden-bitfield-accesses (modulo bikeshedding).<br></p></div></blockquote></span><div>Several different approaches have been discussed in this thread, I'm not sure what you mean about "least-bad solution"...</div><div><br></div><div>I remain completely unconvinced that we should change the default behavior. At most, I'm not strongly opposed to adding an attribute that indicates "please try to use narrow loads for this bitfield member" and is an error if applied to a misaligned or non-byte-sized bitfield member. But I remain strongly opposed to changing the default behavior.</div></div></div></blockquote><div><br></div><div>Having an option and make it off by default for now is a fine solution. We can also use this option to collect more empirical data on a wider range of tests and architectures with the community's help.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> We have one or two cases that regress and are easily addressed by source changes (either to not use bitfields or to use an attribute). I don't think that is cause to change the lowering Clang has used for years and potentially regress many other use cases.</div></div></div></blockquote><div><br></div><div>Note that this is not about that particular cases. It is more about doing the right thing (to make compiler and HW work together to drive the best performance for our users). </div><div><br></div><div>thanks,</div><div><br></div><div>David </div></div><br></div></div>