<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 9:03 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hal already answered much of this, just continuing this part of the discussion...<div><br><div class="gmail_quote"><span class="gmail-"><div dir="ltr">On Wed, Aug 9, 2017 at 8:56 PM Xinliang David Li via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Aug 9, 2017 at 8:37 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span><span class="gmail-">
<p><br>
</p>
<div class="gmail-m_7513022234529944123m_-2021915036012865282m_-1753555538924036895moz-cite-prefix">On 08/09/2017 10:14 PM, Xinliang David
Li via llvm-commits wrote:<br>
</div>
</span><span class="gmail-"><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> Can you elaborate here too? If there were missed
optimization that later got fixed, there should be
regression tests for them, right? And what information is
missing?</div>
</div>
</div>
</div>
</blockquote>
<br></span></span><span class="gmail-">
To make a general statement, if we load (a, i8) and (a+2, i16), for
example, and these came from some structure, we've lost the
information that the load (a+1, i8) would have been legal (i.e. is
known to be deferenceable). This is not specific to bit fields, but
the fact that we lose information on the dereferenceable byte ranges
around memory access turns into a problem when we later can't
legally widen. There may be a better way to keep this information
other than producing wide loads (which is an imperfect mechanism,
especially the way we do it by restricting to legal integer types),</span></div></blockquote></div></div></div></blockquote><div><br></div><div>I don't think we have such a restriction? Maybe I'm missing something. When I originally added this logic, it definitely was not restricted to legal integer types.</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
but at the moment, we don't have anything better.<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Ok, as you mentioned, widening looks like a workaround to paper over the weakness in IR to annotate the information. More importantly, my question is whether this is a just theoretical concern.</div></div></div></div></blockquote><div><br></div></span><div>I really disagree with this being a workaround.</div><div><br></div><div>I think it is very fundamentally the correct model -- the semantics are that this is a single, wide memory operation that a narrow data type is extracted from.</div></div></div></div></blockquote><div><br></div><div><br></div><div>Where is that semantic specified? System ABI certainly says the container storage unit has the same size as the bitfield's type, and the bit field can not cross its storage unit's boundary. A bitfield needs to share the same container storage unit with other bitfield or non bitfield members if the size fit.</div><div><br></div><div>For instance</div><div><br></div><div>struct A{</div><div> unsigned long i: 16;</div><div> unsigned short j: 16;</div><div> unsigned char k; // not bitfield</div><div> unsigned long m: 16;</div><div>};</div><div><br></div><div>All there members have different types but they share the same storage unit with 8 byte in size. 'k' share the same container storage with other bitfields but is not a bitfield. Should it be treated differently?</div><div><br></div><div>Fundamentally, with the current approach of aggressive widening, accesses to struct fields with identical physical layout may produce completely different code with different performance characteristics. For instance, GCC produces identical assembly code for all the cases below, while LLVM does not. While C++ memory model allows bitfield widening does not mean it has to be done blindly without considering impact to later optimizations. I don't consider widening a form of IR normalization.</div><div><br></div><div>Example:</div><div><br></div><div><div>struct A {</div><div>#ifdef LONG_BIT</div><div> unsigned long i:16;</div><div> unsigned long j:16;</div><div>#elif defined(SHORT_BIT)</div><div> unsigned short i:16;</div><div> unsigned short j:16;</div><div>#elif defined (MIX_BIT)</div><div> unsigned long i:16;</div><div> unsigned short j;</div><div>#elif defined (MIX_BIT2)</div><div> unsigned long i:16;</div><div> unsigned short j:16;</div><div>#else</div><div> unsigned short i;</div><div> unsigned short j;</div><div>#endif</div><div>};</div><div><br></div><div>int test (struct A *ap) {</div><div> return ap->i + ap->j;</div><div>}</div></div><div><br></div><div><br></div><div>David</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think the thing that is seriously weak is the ability to aggressively narrow these operations, and while I agree that this is important it doesn't actually seem to be common. We have a relatively small number of (admitedly important) cases, but even our existing narrowing seems to be very effective for the vast majority of cases.</div><div><br></div><div>I would be very hesitant to give up the information preserved by this lowering and representation when we already have very successfully optimized the majority of it effectively during code generation, and have only just started trying a much more aggressive approach. I suspect that the aggressive approach can be made to work, even though it may be quite challenging.</div></div></div>
</blockquote></div><br></div></div>