<div dir="ltr">Thank you, Eli.<div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div>
<br><div class="gmail_quote">2017-12-09 2:03 GMT+07:00 Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div class="m_8682763169478820327moz-cite-prefix">On 12/7/2017 2:16 AM, Serge Pavlov via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hi all,</div>
        <div><br>
        </div>
        <div>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">There is
            some uncertainty in the concept of LLVM IR, which results in
            unexpected IR in
            some cases. The problem description is here: <a href="https://reviews.llvm.org/D40567#943747" target="_blank">https://reviews.llvm.org/<wbr>D40567#943747</a>.
            In short, llvm-link tries to merge an opaque type with its
            definition, using
            type name for that. Clang uses the same name for all
            specializations of a class
            template, so in this case llvm-link chooses arbitrary type
            as a definition. As
            a result the opaque type is mapped to wrong type in IR.</p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US"> </p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">The
            question here is whether the opaque type resolution made by
            llvm-link is a
            correct operation, which in turn depends on what source
            language objects are
            represented in IR.  Variables and
            function must exist in IR because these are entities
            directly represented in
            object files, but types do not have similar requirement.
            There are at least two
            viewpoints on which entities of source language should be
            represented in IR. </p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US"> </p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">Case 1</p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US"> </p>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">LLVM IR
            is a functional equivalent of the compiled program. It tries
            to preserve
            information about externally visible objects (variables,
            functions) that may be
            used in operation on IR modules. In particular, as C++
            defines rules of
            equivalence for types defined in different translation
            units, and these rules
            make opaque type resolution possible, the IR must have an
            equivalent for C++
            type.</p>
        </div>
      </div>
    </blockquote>
    <br></span>
    This simply doesn't reflect reality.  Opaque and identified
    structure types exist to make IR easier to understand for humans;
    the names don't affect the semantics of any IR instruction, and
    transformations frequently throw away types to perform
    optimizations.</div></blockquote><div><br></div><div>It means that the case 2 is true, and type merge should be removed. An operation that essentially depends on the property that is added solely for reading by humans is not a valid IR transformation.</div><div><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"><span class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">In this
            case clang must provide appropriate IR type identification,
            so that the same
            types in different translation units can be recognized. It
            can be made by
            assigning each type a unique name.</p>
        </div>
      </div>
    </blockquote>
    <br></span>
    clang should try to do this anyway; not because we have to, but just
    to make IR easier to read.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    -Eli<br>
    <pre class="m_8682763169478820327moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </font></span></div>

</blockquote></div><br></div></div>