<div dir="ltr">Thanks for the digging!<div><br></div><div>A quick note:</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 16, 2018 at 10:30 AM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@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 text="#000000" bgcolor="#FFFFFF">
    <p><b>Untrusted Declarations</b><br></p>
    <p>In several cases, we check hasExactDefinition before checking
      properties of the function declaration (such as return type).  To
      my knowledge, facts on declarations are valid even in the place of
      derefinement.  This results in the analysis being unnecessarily
      conservative around external declarations.<br></p></div></blockquote><div>We need to be careful here. Totally agree with you, just worried about something somewhere *inferring* things onto declarations when it shouldn't and a general lack of adequate understanding of the line between the good and bad cases...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>
    </p>
    <p><b>AlwaysInline and hasExactDefinition</b></p>
    <p>I believe, but have not fully thought through, that it is legal
      to IPO across an inexact definition boundary if a particularly
      callsite or declaration is marked alwaysinline.  It's not clear
      this matters since we'll eventually inline it anyway, but this
      might be a compile time savings by simplifying callers earlier
      than otherwise possible.<br></p></div></blockquote><div>Given pass ordering, I'd not worry about this. The inliner runs first (in the new PM) and then we deduce attributes so we should already have nuked any always_inline edges.</div><div><br></div><div>We also have the pre-call-graph cleanup passes that do most of the code deletion and such prior to inlining.</div></div></div></div>