diff options
author | Greg Ungerer <gerg@linux-m68k.org> | 2023-11-13 16:32:09 +0300 |
---|---|---|
committer | Geert Uytterhoeven <geert@linux-m68k.org> | 2024-12-09 15:29:17 +0300 |
commit | e419ddeabe7edd89650a19f411f928eea12b35b1 (patch) | |
tree | 3479c722424ecdb4f7f5257570106c241c9f5ec2 /tools/perf/scripts/python/gecko.py | |
parent | 40384c840ea1944d7c5a392e8975ed088ecf0b37 (diff) | |
download | linux-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