<html>
    <head>
      <base href="https://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 --- - [GlobalISel] Value to vreg during IR to MachineInstr translation for aggregate type"
   href="https://llvm.org/bugs/show_bug.cgi?id=26161">26161</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[GlobalISel] Value to vreg during IR to MachineInstr translation for aggregate type
          </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>Common Code Generator Code
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>qcolombet@apple.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>The design to handle aggregate types during IR translation in GlobalISel will
need to be revisited to at least acknowledge that we choose the right approach.

At first, this is not critical that we don’t support aggregate types, thus a
simple mapping one Value* to one Vreg is perfectly fine.

When we would add the support for such types, we have basically two options:
1. Replicate SDAG solution, i.e., more or less map one Value* to a list of
Vregs (one Vreg per component).
2. Keep the mapping simple, i.e., one Value* to one (big) Vreg.

The pros and cons are discussed in the following thread:
<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-January/094049.html">http://lists.llvm.org/pipermail/llvm-dev/2016-January/094049.html</a>

Although #2 seems preferable, we don’t have any actual experience on how well
we would be to optimize this representation.</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>