<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thank you so much, again!</p>
    <p><br>
    </p>
    <p>I can't overstate how useful all these recommendations are, and
      I'm looking forward to see how these play out in simulations. So I
      guess it's time for me to work!</p>
    <p><br>
    </p>
    <p>Sincerely yours,</p>
    <p>Dani.<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 18/4/25 14:41, Sven Tennie wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CALgrwrb+tHz9c0rH9G45ydmNQX5PV6rVBCyLf8BCSf_t4ib2oA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hey Daniel ðŸ‘‹</div>
        <div><br>
        </div>
        <div>Thanks a lot for your kind words.</div>
        <div><br>
        </div>
        <div>The AArch64 ISA might also be some source of inspiration.
          AArch64 has some combined instructions which RISC-V hasn't.
          E.g ADD of two registers with an included shift. Though, we
          don't seem to use many of them and I haven't found any usage
          that wouldn't be well covered in RISC-V NCG. Probably, that's
          because MachOp (<a
href="https://hackage.haskell.org/package/ghc-9.12.1/docs/GHC-Cmm-MachOp.html#t:MachOp"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://hackage.haskell.org/package/ghc-9.12.1/docs/GHC-Cmm-MachOp.html#t:MachOp</a>)
          is pretty fine grained.</div>
        <div><br>
        </div>
        <div>A good candidate for investigations could be the CSET
          pseudo-instruction. I stumbled over it while looking for
          pseudo-ops which lead to combined instructions in AArch64 NCG.
          The CSET pseudo-op leads to two instructions in RISC-V NCG and
          to one in AArch64 NCG:</div>
        <div>- <a
href="https://gitlab.haskell.org/ghc/ghc/-/blob/386f18548e3c66d04f648a9d34f167a086c1328b/compiler/GHC/CmmToAsm/AArch64/Ppr.hs#L443"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/blob/386f18548e3c66d04f648a9d34f167a086c1328b/compiler/GHC/CmmToAsm/AArch64/Ppr.hs#L443</a></div>
        <div>- <a
href="https://gitlab.haskell.org/ghc/ghc/-/blob/386f18548e3c66d04f648a9d34f167a086c1328b/compiler/GHC/CmmToAsm/RV64/Ppr.hs#L554"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/blob/386f18548e3c66d04f648a9d34f167a086c1328b/compiler/GHC/CmmToAsm/RV64/Ppr.hs#L554</a></div>
        <div><br>
        </div>
        <div>Though, this might be a sub-optimal implementation (in this
          case we'd be happy to get a ticket ;) ). As CSET is used for
          comparisons, it should appear pretty frequently.<br>
        </div>
        <div><br>
        </div>
        <div>A bit off-topic, but for the sake of completeness: The
          Compiler Explorer seems to use DWARF symbols to map assembly
          instructions to Haskell code lines. At least, it compiles with
          -g.<br>
        </div>
        <div><br>
        </div>
        <div>VELDT's profile is stated as "RV32I (no FENCE, ECALL,
          EBREAK)" on their Github page. But, we target RV64G with both,
          the NCG and LLVM backends. (The main reason to not support
          simpler profiles is that all hardware on the market that is
          powerful enough to reasonably run Haskell supports at least
          RV64G.)</div>
        <div><br>
        </div>
        <div>Thanks for the hint about the J-extension. I will take a
          look at it.<br>
        </div>
        <div><br>
        </div>
        <div>Enjoy your weekend & best regards,</div>
        <div><br>
        </div>
        <div>Sven<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">Am Fr., 18. Apr. 2025 um
          12:13 Uhr schrieb Daniel Trujillo Viedma <<a
            href="mailto:danihacker.viedma@gmail.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">danihacker.viedma@gmail.com</a>>:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <p>Thank you so much for all the information and the help.<br>
            </p>
            <p><br>
            </p>
            <p>Seriously, this is much more than I was hoping to get,
              even the suggestion for generating commented assembly code
              (which is, I assume, the method that Compiler Explorer
              uses to relate the high-level Haskell code with the
              assembly output of the compiler, which is really nice).
              And four your RISC-V NGC, which I found easy to
              understand.</p>
            <p><br>
            </p>
            <p>I guess this is the kind of professionals that Haskell
              attracts, which is a big part of why I love it.</p>
            <p><br>
            </p>
            <p>I will send here an executive summary of my findings,
              including statistics about a couple of programs that I
              try. I don't know if I'll be able to do a very statistical
              significant analysis, because I'll still have a lot of
              things to do (to extend QEMU, maybe also gem5, and
              implement it in a Clash microprocessor design, probably
              VELDT), but maybe in the future I can automate more of it
              and running a more comprehensive analysis. FYI, I have
              found that the RISC-V specs mention Haskell among other
              languages in a still empty J extension section, which will
              be aimed at helping dynamically translated languages as
              well as garbage-collected, but I guess RISC-V people is
              still more focused on other things and it will take some
              time to start work on that extension.</p>
            <p><br>
            </p>
            <p>I find also very interesting your suggestion for
              far-jumping, but I'm afraid that will be very unpopular
              among hardware designers because it messes with their
              highly appreciated and scarce L1 cache. But funnily
              enough, I had the impresion before starting this project
              that some kind of simple mechanism for complex jumping
              would be a good idea. I will keep this in mind when
              looking for patterns in the assembly code.<br>
            </p>
            <p><br>
            </p>
            <p>Once more, thank you so much for your work and the help,
              and I hope I can deliver soon information that you all
              could find interesting.</p>
            <p><br>
            </p>
            <p>Have a very nice weekend!</p>
            <p>Cheers,</p>
            <p>Dani.<br>
            </p>
            <p><br>
            </p>
            <div>On 17/4/25 9:19, Sven Tennie wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div>Hey Daniel ðŸ‘‹</div>
                <div><br>
                </div>
                <div>That's really an interesting topic, because we
                  never analyzed the emitted RISC-V assembly with
                  statistical measures.</div>
                <div><br>
                </div>
                <div>So, if I may ask for a favour: If you spot anything
                  that could be better expressed with the current ISA,
                  please open a ticket and label it as RISC-V: <a
                    href="https://gitlab.haskell.org/ghc/ghc/-/issues"
                    target="_blank" moz-do-not-send="true"
                    class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/issues</a>
                  <br>
                </div>
                <div>(We haven't decided which RISC-V profile to
                  require. I.e. requiring the very latest extensions
                  would frustrate people with older hardware... However,
                  it's in anycase good to have possible improvements
                  documented in tickets.)<br>
                </div>
                <div><br>
                </div>
                <div>I'm wondering if you really have to go through
                  QEMU. Or, if feeding assembly code to a parser and
                  then doing the math on that wouldn't be sufficient?
                  (Of course, tracing the execution is more accurate.
                  However, it's much more complicated as well.)</div>
                <div><br>
                </div>
                <div>To account Assembly instructions to Cmm statements
                  you may use the GHC parameters -ddump-cmm and
                  -dppr-debug (and to stream this into files instead of
                  stdout -ddump-to-file.) This will add comments for
                  most Cmm statements into the dumped assembly code.</div>
                <div><br>
                </div>
                <div>At first, I thought that sign-extension /
                  truncation might be a good candidate. However, it
                  turned out that this is already covered by the RISC-V
                  B-extension. Which led to this new ticket: <a
href="https://gitlab.haskell.org/ghc/ghc/-/issues/25966" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/issues/25966</a></div>
                <div><br>
                </div>
                <div>Skimming over the NCG code and watching out for
                  longer or repeating instruction lists might be a good
                  strategy to make educated guesses.</div>
                <div><br>
                </div>
                <div><span style="font-family:arial,sans-serif">From a
                    developer's perspective, I found the immediate sizes
                    (usually 12bit) rather limiting. E.g. the </span>Note
                  [RISCV64 far jumps] (<a
href="https://gitlab.haskell.org/ghc/ghc/-/blob/395e0ad17c0d309637f079a05dbdc23e0d4188f6/compiler/GHC/CmmToAsm/RV64/CodeGen.hs?page=2#L1996"
                    target="_blank" moz-do-not-send="true"
                    class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/blob/395e0ad17c0d309637f079a05dbdc23e0d4188f6/compiler/GHC/CmmToAsm/RV64/CodeGen.hs?page=2#L1996</a>)
                  tells a story how we had to work around this limit for
                  addresses in conditional jumps.</div>
                <div><br>
                </div>
                <div>So, you could raise the question if - analog to
                  compressed expressions - it wouldn't make sense to
                  have extended expressions that cover two words. Such
                  that the first word is the instruction and the second
                  it's immediate(s). (Hardware designers would probably
                  hate that, because it means a bigger change to the
                  instruction decoding unit. However, I got asked as a
                  software developer ;) )</div>
                <div><br>
                </div>
                <div>Other than that, I've unfortunately got no great
                  ideas.</div>
                <div><br>
                </div>
                <div>Please feel free to keep us in the loop (especially
                  regarding the results of your analyses.) And, if
                  you've got any questions regarding the RISC-V NCG,
                  please feel free to reach out either here or directly
                  to me. There's also a #GHC "room" on Matrix where you
                  can quickly drop smaller scoped questions.</div>
                <div><br>
                </div>
                <div>I hope that was of any help. Best regards,</div>
                <div><br>
                </div>
                <div>Sven<br>
                </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">Am Mi., 16. Apr. 2025
                  um 10:34 Uhr schrieb Matthew Pickering <<a
                    href="mailto:matthewtpickering@gmail.com"
                    target="_blank" moz-do-not-send="true"
                    class="moz-txt-link-freetext">matthewtpickering@gmail.com</a>>:<br>
                </div>
                <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                  <div dir="ltr">
                    <div>Hi Daniel. I think Sven Tennie and the
                      LoongArch contributors are the experts in NCG for
                      these kinds of instruction sets. I have cced them.</div>
                    <div><br>
                    </div>
                    <div>Cheers,</div>
                    <div><br>
                    </div>
                    <div>Matt</div>
                  </div>
                  <br>
                  <div class="gmail_quote">
                    <div dir="ltr" class="gmail_attr">On Tue, Apr 15,
                      2025 at 5:40 PM Daniel Trujillo Viedma <<a
                        href="mailto:danihacker.viedma@gmail.com"
                        target="_blank" moz-do-not-send="true"
                        class="moz-txt-link-freetext">danihacker.viedma@gmail.com</a>>
                      wrote:<br>
                    </div>
                    <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,
                      ghc-devs! My name is Daniel Trujillo, I'm a
                      Haskell enthusiast <br>
                      from Spain and I'm trying to make my Master's
                      thesis about accelerating <br>
                      Haskell programs with a custom ISA extension.<br>
                      <br>
                      <br>
                      Right now, my focus is in executing software
                      written in Haskell within <br>
                      QEMU in order to get traces that tells me,
                      basically, how many times <br>
                      each block (not exactly basic blocks, but sort of)
                      of assembly code has <br>
                      been executed, with the hope of finding some
                      patterns of RISCV <br>
                      instructions that I could implement together into
                      1 instruction.<br>
                      <br>
                      <br>
                      As you can see, my method is a bit crude, and I
                      was wondering if the <br>
                      people involved with any of the different internal
                      representations (STG, <br>
                      Cmm...) and/or native code generators
                      (particularly RISCV) could provide <br>
                      me hints about assembly instructions that would
                      have made the work <br>
                      easier, by removing the need of "massaging" the
                      Cmm code to make CodeGen <br>
                      easier, or the need of particular optimizations,
                      or in general, dirty <br>
                      tricks because of lacking of proper support of the
                      standard RISCV ISA.<br>
                      <br>
                      <br>
                      And of course, I would also appreciate very much
                      other hints from people <br>
                      involved in general performance (as oppossed to,
                      for example, libraries <br>
                      for SIMD and parallel execution, or Haskell
                      wrappers to lower-level code <br>
                      for performance reasons).<br>
                      <br>
                      <br>
                      P.D. I'm sorry if I broke any netiquette rule, but
                      I'm very new to the <br>
                      email list, and haven't received yet any email
                      from it.<br>
                      <br>
                      <br>
                      Looking forward to hear from you!<br>
                      <br>
                      Cheers,<br>
                      <br>
                      Dani.<br>
                      <br>
                      _______________________________________________<br>
                      ghc-devs mailing list<br>
                      <a href="mailto:ghc-devs@haskell.org"
                        target="_blank" moz-do-not-send="true"
                        class="moz-txt-link-freetext">ghc-devs@haskell.org</a><br>
                      <a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true"
                        class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
                    </blockquote>
                  </div>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>