<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Separate User from the Value inheritance hierarchy"
href="http://llvm.org/bugs/show_bug.cgi?id=21438">21438</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Separate User from the Value inheritance hierarchy
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Core LLVM classes
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dexonsmith@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Currently, `User` inherits from `Value`. Most subclasses of `Value` -- even
those that don't have the concept of an operand -- inherit from `User`.
Instead, we should separate `User` from the `Value` inheritance hierarchy.
The current model is strange for operand-less `Instruction`s and `Constant`s.
Moreover, it makes the inheritance structure of the new metadata types from <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - First-class (metadata-based) IR for debug info"
href="show_bug.cgi?id=21432">bug
21432</a> especially awkward [1].
[1]: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078261.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078261.html</a>
See the comments about the relationships between MDNode/MDString/MDUser.
**Design needed.** Nevertheless, here's the sketch of a straw man:
1. `Value` has a bit indicating whether it's a `User` (perhaps borrowed from
`ValueName *Name`).
2. `Use::getUser()` returns `Value` and asserts that the bit is set.
Alternatively, it returns a wrapper around `Value *` called `UserRef` that has
operand-related API.
3. Eventual subclasses of `Value` that have operands use multiple inheritance
to inherit from `User`. Note that every child of `User` already needs to
specialize `User` with `OperandTraits`, so this doesn't add boilerplate -- in
fact, it should clean it up a bit.
4. Change the `Use *OperandList` in `User` to be allocated in front of it
(like the operands in `FixedNumOperandTraits`). This makes it accessible from
`Value` without knowing the common subclass between `Value` and `User`.
I won't have time in the short-term to design, qualify, and roll this out, but
I thought I'd get the idea down while the issues are paged in.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>