<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/7/2017 2:16 AM, Serge Pavlov via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACOhrX7w_Z0emBsR334+sZ7CtMsGJNoPXMk=3KGogMBO7e5T6A@mail.gmail.com">
<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"
moz-do-not-send="true">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>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACOhrX7w_Z0emBsR334+sZ7CtMsGJNoPXMk=3KGogMBO7e5T6A@mail.gmail.com">
<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>
clang should try to do this anyway; not because we have to, but just
to make IR easier to read.<br>
<br>
-Eli<br>
<pre class="moz-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>
</body>
</html>