<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </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 - RISC-V DataLayout is wrong which causes many optimizations to not work on RISC-V"
   href="https://bugs.llvm.org/show_bug.cgi?id=45708">45708</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>RISC-V DataLayout is wrong which causes many optimizations to not work on RISC-V
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>new-bugs
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>new bugs
          </td>
        </tr>

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

        <tr>
          <th>Reporter</th>
          <td>heikki.kultala@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>The RV32I and RV64I Base ISAs supports 8-bit and 16-bit memory operations, AND
they support unaligned memory operations.

However, on LLVM

RISCV32 data layout is just "e-m:e-p:32:32-i64:64-n32-S128",
and RISCV64 data layout is just "e-m:e-p:64:64-i64:64-i128:128-n64-S128".

These lacks information about 8- and 16-bit data types, and also the alignment
for 32 and 64 bit memory accesses is wrong.

Because the data layout forces aligned memory accesses, the backend generates
very slow code consisting of multiple narrower accesses when it cannot prove
that a memory access is aligned.

And the total lack of information about 8-bit and 16-bit accesses in the data
layout makes clang think 8-bit and 16-bit types or memory accesses are not
legal, which prevents some optimizations from working, for example
-ffine-grained-bitfield-accesses fails to generate 8-bit or 16-bit accesses
because there is a check that it only generates legal loads.</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>