https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |meissner at gcc dot gnu.org
--- Comment #32 from Michael Meissner <meissner at gcc dot gnu.org> ---
I looked at adding the following powerpc patch that was proposed in March,
2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566744.html
There are two parts to the patch, that are sort of unrelated.
The first part is to add minimum and maximum section anchor offset values and
use -fsection anchors. I ran a spec 2017 benchmark on a pre-production power10
system, comparing my normal run times to run times with -fsection-anchors and
setting the minimum/maximum section anchor offsets.
Two benchmarks improved and two benchmarks regressed:
xalancbmk_r: 1.75% regression
cactuBSSN_r: 4.24% improvement
blender_r: 1.92% regression
roms_r: 1.05% improvement
I then built spec 2017 with just the part of setting const_anchor, but not the
section anchor minimum/maximum offsets. Eight benchmarks did not build due to
assertion failures in cse.c:
gcc_r
exchange2_r
cactuBSSN_r
wrf_r
blender_r
cam4_r
fotonik3d_r
roms_r
If I specify the section anchor minimum/maximum offsets, add -fsection-anchors,
and set the const_anchor, all 23 INT+FP benchmarks build, but WRF_R does not
run correctly. So without more debugging, I don't recommend setting
const_anchor. It is probably useful to set the minimum/maximum section anchor
offsets in case people use -fsection-anchors.
As an aside, if we wanted to accept using constant addresses in the PowerPC, we
would need to recognize a constant address as being legitimate. This may be
useful in some embedded environments where you have devices at certain memory
locations. But somebody would need to add the support.
