Questions regarding the RISCV native codegen & performance

[Sven Tennie]

Hey Daniel 👋

That's really an interesting topic, because we never analyzed the emitted
RISC-V assembly with statistical measures.

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: https://gitlab.haskell.org/ghc/ghc/-/issues
(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.)

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.)

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.

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:
https://gitlab.haskell.org/ghc/ghc/-/issues/25966

Skimming over the NCG code and watching out for longer or repeating
instruction lists might be a good strategy to make educated guesses.

>From a developer's perspective, I found the immediate sizes (usually 12bit)
rather limiting. E.g. the Note [RISCV64 far jumps] (
https://gitlab.haskell.org/ghc/ghc/-/blob/395e0ad17c0d309637f079a05dbdc23e0d4188f6/compiler/GHC/CmmToAsm/RV64/CodeGen.hs?page=2#L1996)
tells a story how we had to work around this limit for addresses in
conditional jumps.

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 ;) )

Other than that, I've unfortunately got no great ideas.

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.

I hope that was of any help. Best regards,

Sven

Am Mi., 16. Apr. 2025 um 10:34 Uhr schrieb Matthew Pickering <
matthewtpickering at gmail.com>:

> 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.
>
> Cheers,
>
> Matt
>
> On Tue, Apr 15, 2025 at 5:40 PM Daniel Trujillo Viedma <
> danihacker.viedma at gmail.com> wrote:
>
>> Hello, ghc-devs! My name is Daniel Trujillo, I'm a Haskell enthusiast
>> from Spain and I'm trying to make my Master's thesis about accelerating
>> Haskell programs with a custom ISA extension.
>>
>>
>> Right now, my focus is in executing software written in Haskell within
>> QEMU in order to get traces that tells me, basically, how many times
>> each block (not exactly basic blocks, but sort of) of assembly code has
>> been executed, with the hope of finding some patterns of RISCV
>> instructions that I could implement together into 1 instruction.
>>
>>
>> As you can see, my method is a bit crude, and I was wondering if the
>> people involved with any of the different internal representations (STG,
>> Cmm...) and/or native code generators (particularly RISCV) could provide
>> me hints about assembly instructions that would have made the work
>> easier, by removing the need of "massaging" the Cmm code to make CodeGen
>> easier, or the need of particular optimizations, or in general, dirty
>> tricks because of lacking of proper support of the standard RISCV ISA.
>>
>>
>> And of course, I would also appreciate very much other hints from people
>> involved in general performance (as oppossed to, for example, libraries
>> for SIMD and parallel execution, or Haskell wrappers to lower-level code
>> for performance reasons).
>>
>>
>> P.D. I'm sorry if I broke any netiquette rule, but I'm very new to the
>> email list, and haven't received yet any email from it.
>>
>>
>> Looking forward to hear from you!
>>
>> Cheers,
>>
>> Dani.
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250417/c5a5fcdf/attachment.html>