Skip to content

AArch64: Add UMULH and UMULL instructions for timesWord2#

Alex Mason requested to merge Axman6/ghc:wip/aarch64-UMULH-instruction into master

This patch adds the AArch64 UMULH and UMULL instructions, and provides implementations for MO_S_Mul2 and MO_U_Mul2 for 64 bit (using UMULH/SMULLH) and < 64 bit (using UMULL/SMULL). Currently the unsigned versions can't be produced; producing MO_U_Mul2 is guarded by stgToCmmAllowExtendedAddSubInstrs, which is False for AArch64. I don't know what the implications of adding it to the list would be, so I haven't touched the StgToCmm config.

(Update, Feb 2024) I've added stgToCmmAllowWordMul2Instr to StgToCmmConfig as it seems strange to link mul2 to stgToCmmAllowExtendedAddSubInstrs.

!8392 also splits out cmmAllowMul2, which seems like the right thing to do, and having this MR in place would make that MR much more efficient. I'm currently in the process of reviewing it (though think there might be a more efficient algorithm using UMULH/SMULH than the Hacker's Delight one).

I've added a test to verify that the combined result of the high and low multiply can be combined into the expected Integer.

If the unsigned case can be enabled, this should significantly improve the performance of multiplication of BigNat# on AArch64 (I haven't benchmarked this but I would be shocked if the two instruction implementation was somehow slower than the twenty or so instructions needed to emulate UMULH). Doing so would solve #22933.

Please take a few moments to address the following points:

  • if your MR may break existing programs (e.g. touches base or causes the compiler to reject programs), please describe the expected breakage and add the ~"user facing" label. This will run ghc/head.hackage> to characterise the effect of your change on Hackage.
  • ensure that your commits are either individually buildable or squashed
  • ensure that your commit messages describe what they do (referring to tickets using #NNNN syntax when appropriate)
  • have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places.
  • add a testcase to the testsuite.
  • updates the users guide if applicable
  • mentions new features in the release notes for the next release
Edited by Alex Mason

Merge request reports