https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117006
Hongtao Liu <liuhongt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|liuhongt at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #8 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #7)
> (In reply to Hongtao Liu from comment #6)
> > (In reply to Jakub Jelinek from comment #5)
> > > So if anything, one would need to decide this on something larger rather
> > > than small testcases, say build the whole gcc with -Os + once again with
> > > the
> > > revision reverted (or SPEC or firefox or something large) and compare
> > > overall sizes if something is generally a win or not.
> >
> > I'll compare the impact of the commit on SPEC2017 with Os to see if the
> > change need to be guarded under speed only.
>
> overall, the commit reduce codesize a little bit with -march=x86-64 Os
>
> 500.perlbench_r 0.07%
> 502.gcc_r -0.02%
> 505.mcf_r 0.04%
> 520.omnetpp_r 0.10%
> 523.xalancbmk_r 0.01%
> 525.x264_r -0.01%
> 531.deepsjeng_r 0.01%
> 541.leela_r -0.09%
> 548.exchange2_r -0.23%
> 557.xz_r -0.12%
> 503.bwaves_r 0.00%
> 507.cactuBSSN_r 0.00%
> 508.namd_r 0.01%
> 510.parest_r 0.00%
> 511.povray_r 0.02%
> 519.lbm_r 0.07%
> 521.wrf_r 0.06%
> 526.blender_r -0.01%
> 527.cam4_r 0.02%
> 538.imagick_r 0.01%
> 544.nab_r 0.02%
> 549.fotonik3d_r -0.04%
> 554.roms_r -0.67%
> ALL -0.03%
Overall, it doesn't look like a regression to me, the codesize even shrinks a
little bit.
