<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">https://reviews.llvm.org/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>

<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">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>

<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 2</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 low-level representation designed for code generation. Some information
about externally visible objects may be lost, it is expectable. In particular,
IR types belong solely to internal machinery, they have no relation to types
used in source language.</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">In this
case opaque type name resolution made by llvm-link is incorrect operation and
must be removed. Only functions and variables may be merged and opaque type
resolution may occur only as a side-effect of such merge. </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"><br></p>

<p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US">It looks
like now clang and llvm-link follow different concepts.</p>

<p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US"><span style="font-size:11pt">I wonder which viewpoint complies with the IR design.</span><br></p></div><br clear="all"><div><div class="gmail_signature">Thanks,<br>--Serge<br></div></div>
</div>