<div dir="ltr">Hal already answered much of this, just continuing this part of the discussion...<div><br><div class="gmail_quote"><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">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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span>
    <p><br>
    </p>
    <div class="m_-2021915036012865282m_-1753555538924036895moz-cite-prefix">On 08/09/2017 10:14 PM, Xinliang David
      Li via llvm-commits wrote:<br>
    </div>
    <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>
    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),</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><div><br></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_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    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><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><br></div><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></div>