summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/gecko.py
diff options
context:
space:
mode:
authorGreg Ungerer <gerg@linux-m68k.org>2023-11-13 16:32:09 +0300
committerGeert Uytterhoeven <geert@linux-m68k.org>2024-12-09 15:29:17 +0300
commite419ddeabe7edd89650a19f411f928eea12b35b1 (patch)
tree3479c722424ecdb4f7f5257570106c241c9f5ec2 /tools/perf/scripts/python/gecko.py
parent40384c840ea1944d7c5a392e8975ed088ecf0b37 (diff)
downloadlinux-e419ddeabe7edd89650a19f411f928eea12b35b1.tar.xz
m68k: Use kernel's generic muldi3 libgcc function
Use the kernels own generic lib/muldi3.c implementation of muldi3 for 68K machines. Some 68K CPUs support 64bit multiplies so move the arch specific umul_ppmm() macro into a header file that is included by lib/muldi3.c. That way it can take advantage of the single instruction when available. There does not appear to be any existing mechanism for the generic lib/muldi3.c code to pick up an external arch definition of umul_ppmm(). Create an arch specific libgcc.h that can optionally be included by the system include/linux/libgcc.h to allow for this. Somewhat oddly there is also a similar definition of umul_ppmm() in the non-architecture code in lib/crypto/mpi/longlong.h for a wide range or machines. Its presence ends up complicating the include setup and means not being able to use something like compiler.h instead. Actually there is a few other defines of umul_ppmm() macros spread around in various architectures, but not directly usable for the m68k case. Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/20231113133209.1367286-1-gerg@linux-m68k.org Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diffstat (limited to 'tools/perf/scripts/python/gecko.py')
0 files changed, 0 insertions, 0 deletions