[PATCH] Improve and consolidate sparc PIC assembler.
tg at gmplib.org
Mon Apr 15 17:13:34 CEST 2013
Where to go from here? If we want to "clean up" some old SPARC code,
then we have learnt that we to test the result on several key platforms.
We also don't want to create slower code, unless the old code is clearly
broken (in more than a hypothetical way).
For the 64bit case, it is safe to assume that GMP's internal references
are not > 2GiB away from the code. GMP is not that bloated! :-)
We therefore do not need to mess with 64-bit or even 44-bit offsets in
PIC; doing that is just slower. *External* references is a different
story, and if we ever get the urge to refer such symbols from assembly
code, we need a slower/larger code sequence.
We may well put data in the text segment rather than rodata to allow for
plainer code. (Incidentally, this same might be a bad idea of x86,
where some processors refuse to keep a cache line in both I-cache and
D-cache, and we might end up with a false sharing situation. That can
happen as a result of speculative instruction prefetch, even if we align
things to a cache line.)
64-bit static address generation is a pain. It adds a lot of overhead.
I wonder if it is ever going to be used.
More information about the gmp-devel