This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 20 Mar 2015 13:44:04 -0400
- Subject: Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Authentication-results: sourceware.org; auth=none
- References: <20150305200638 dot GA3059 at ibm-tiger dot the-meissners dot org> <CAGWvnymp1VoTfGpgxmPwbsWcnTVrZin1-etCAvOHJ0UMaHbzMA at mail dot gmail dot com> <20150311222120 dot GA16631 at ibm-tiger dot the-meissners dot org> <CAGWvny=AQdkVqZ=Ps-AXd-e7Q2pD_k=KS=5QaYqp4jGNcKWdgg at mail dot gmail dot com> <20150312152952 dot GA11678 at ibm-tiger dot the-meissners dot org> <CAGWvnykFGnTxN+m2-fF9aZ6VtmXx3bXKD+MzMGvrH-U0=kMjeA at mail dot gmail dot com> <20150317231840 dot GA24459 at ibm-tiger dot the-meissners dot org> <CAFiYyc0qLRYMwR5Omz9UOWixw3mdEp79pkz9jMvOymPH-pmBVQ at mail dot gmail dot com>
On Wed, Mar 18, 2015 at 12:08:47PM +0100, Richard Biener wrote:
> Did you double-check if there are any differences in generated code?
> Esp. the SPEC INT benchmarks look odd - they don't contain any
> FP code.
SpecINT does contain some amount of floating point. Off the top of my head:
1) Bzip2 does a percentage calculation for fprintf;
2) Libquantum uses sin/cos (which the compiler optimizes to sincos) in the
initial setup to set up the data.
3) I don't recall if the version of GCC used in Spec had switched over to
using floating point for the register allocator or not.
4) Perlbench has a lot of code that does floating pointing point, but the
main loop excerised in the Spec runs probably doesn't use FP.
Sorry I couldn't respond earlier, the corporate IMAP email server was down for
a period of time.
Any way, I do see code changes.
Before the fix was made, if you used -ffast-math, it kept the floating point
constants around until reload. When reload could not find a reload to load the
constant, it would push the constant to memory, and do validize_mem on the
address. This created the sequence:
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lfd 0,0(9)
Because the address was a single register, it could also load the value into
the traditional Altivec registers:
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lxsdx 32,0(9)
And in fact the register allocator seemed to prefer loading constants into the
traditional Altivec registers instead of the traditional floating point
registers.
Once I made the change to force the constant to memory earlier, it would use
normal addressing, and generate something like:
addis 9,2,.LC0@toc@ha
lfs 0,.LC0@toc@l(9)
This meant that a lot of addi's are no longer generated, because the addi is
folded into the lfs/lfd instruction.
In addition, due to the VSX memory instructions being only register+register,
whenever the code wanted to load floating point constants, it would prefer the
traditional floating point registers which had register+offset addressing.
This meant in turn, that any instruction that used a FP constant could
potentially be changed from a VSX form (i.e. xsmuldp) into a traditional FP
form (i.e. fmul) if all of the inputs and outputs were traditional floating
point registers.
Finally, I suspect pushing the address out earlier, means that it might be
keeping the address live a little bit longer, which could change things if we
are spilling GPRs. One of the things I am working on for GCC 6.0 is going back
to reworking on the address support to do a better job with fusion, and I
believe it will reduce the life time for some of these address temporaries.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797
- References:
- [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
- Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math