Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?
On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore
wrote:
> Consider this bit of code:
>
> extern double a[20];
>
> double test1 (int n)
> {
> double accum = 0.0;
> int i;
>
> for (i=0; i accum = fabs (accum);
> return accum;
> }
>
> which is compiled for MIPS using
>
> mipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1 -S
> abstest.c
>
> With a GCC 4.6 compiler, this produces:
> ...
> .L3:
> mtc1 $3,$f2
> ldc1 $f0,0($5)
> addiu $5,$5,8
> mtc1 $2,$f3
> sub.d $f2,$f2,$f0
> mfc1 $3,$f2
> bne $5,$4,.L3
> mfc1 $2,$f3
>
> ext $5,$2,0,31
> move $4,$3
> .L2:
> mtc1 $4,$f0
> j $31
> mtc1 $5,$f1
> ...
>
> This is terrible code, with all that pointless register-shuffling inside the
> loop -- what's gone wrong? Well, the bit-twiddling expansion of "fabs"
> produced by optabs.c uses subreg expressions, and on MIPS
> CANNOT_CHANGE_MODE_CLASS disallows use of FP registers for integer
> operations. And, when IRA sees that, it decides it cannot alloc "accum" to
> a FP reg at all, even if it obviously makes sense to put it there for the
> rest of its lifetime.
>
> On mainline trunk, things are even worse as it's spilling to memory, not
> just shuffling between registers:
>
> .L3:
> ldc1 $f0,0($2)
> addiu $2,$2,8
> sub.d $f2,$f2,$f0
> bne $2,$3,.L3
> sdc1 $f2,0($sp)
>
> lw $2,0($sp)
> ext $3,$2,0,31
> lw $2,4($sp)
> .L2:
> sw $2,4($sp)
> sw $3,0($sp)
> lw $3,4($sp)
> lw $2,0($sp)
> addiu $sp,$sp,8
> mtc1 $3,$f0
> j $31
> mtc1 $2,$f1
>
> I've been experimenting with a patch to the MIPS backend to add
> define_insn_and_split patterns for floating-point abs -- the idea is to
> attach some constraints to the insns to tell IRA it needs a GP reg for these
> operations, so it can apply its usual cost analysis and reload logic instead
> of giving up. Then the split to introduce the subreg expansion happens
> after reload when we already have the right register class. This seems to
> work well enough on 4.6; for this particular example, I'm getting:
>
> .L3:
> ldc1 $f2,0($2)
> addiu $2,$2,8
> bne $2,$4,.L3
> sub.d $f0,$f0,$f2
>
> mfc1 $2,$f1
> ext $2,$2,0,31
> j $31
> mtc1 $2,$f1
>
> However, same patch on mainline is still giving spills to memory. :-(
>
> So, here's my question. Is it worthwhile for me to continue this approach
> of trying to make the MIPS backend smarter? Or is the way IRA deals with
> CANNOT_CHANGE_MODE_CLASS fundamentally broken and in need of fixing in a
> target-inspecific way? And/or is there some other regression in IRA on
> mainline that's causing it to spill to memory when it didn't used to in 4.6?
>
> BTW, the unary "neg" operator has the same problem as "abs" on MIPS; can't
> use the hardware instruction because it does the wrong thing with NaNs, and
> can't twiddle the sign bit directly in a FP register. With both abs/neg now
> generating unnecessary memory spills, this seems like a fairly important
> performance regression
It sounds like IRA would benefit from properly split live-ranges here.
You could try
to make the fabs optabs magic make sure to use a new pseudo (well, and hope
that survives ...)
Richard.
> -Sandra
>
>
Re: RFC: PATCH: Require and use int64 for x86 options
On Wed, Jul 27, 2011 at 2:37 PM, H.J. Lu wrote: > On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers > wrote: >> On Wed, 27 Jul 2011, H.J. Lu wrote: >> >>> ; Maximum number of mask bits in a variable. >>> MaxMaskBits >>> ix86_isa_flags = 64 >>> >>> It mark ix86_isa_flags as 64bit. Any comments? >> >> The patch won't work as is. set_option, for example, casts a pointer to >> (int *), and stores a mask that came from option->var_value, which is an >> int, so this won't work with option fields not of type int or values that >> don't fit in int; you'd need to check all uses of CLVC_BIT_CLEAR and >> CLVC_BIT_SET in the source tree to adapt things for the possibility of >> wider mask fields, and track the type of each such field. > > We will prepare a separate patch. > >> Independently, I approve of setting need_64bit_hwint for all x86 targets, >> but your patch doesn't achieve the expected simplification. In >> config.gcc, there are settings for various individual targets that should >> be removed once it's set in one place for all x86 targets. In >> libcpp/configure.ac, similarly the cases for i[34567]86-*-darwin* >> i[34567]86-*-solaris2.1[0-9]* x86_64-*-solaris2.1[0-9]* >> i[34567]86-w64-mingw* i[34567]86-*-linux* (the last only if >> --enable-targets=all) should all be removed as obsolete once >> i[34567]86-*-* is there along with x86_64-*-*. >> > > Is this patch OK for trunk? > > Thanks. > > H.J. > > gcc/ > > 2011-07-27 H.J. Lu > > * config.gcc: Set need_64bit_hwint to yes for x86 targets. > > libcpp/ > > 2011-07-27 H.J. Lu > > * configure.ac: Set need_64bit_hwint to yes for x86 targets. > * configure: Regenerated. > Bootstrapped on Linux/ia32. I am checking it in. Thanks. -- H.J.
Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?
On 07/28/2011 02:11 AM, Richard Guenther wrote: On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore wrote: [snip] So, here's my question. Is it worthwhile for me to continue this approach of trying to make the MIPS backend smarter? Or is the way IRA deals with CANNOT_CHANGE_MODE_CLASS fundamentally broken and in need of fixing in a target-inspecific way? And/or is there some other regression in IRA on mainline that's causing it to spill to memory when it didn't used to in 4.6? It sounds like IRA would benefit from properly split live-ranges here. You could try to make the fabs optabs magic make sure to use a new pseudo (well, and hope that survives ...) That was actually the first thing I tried, and it didn't work -- the new pseudo was eliminated well before it got to the RA. I was thinking vaguely that this could be fixed in IRA by having an additional target hook to supply a reload register class to try for cases where CANNOT_CHANGE_MODE_CLASS is true (typically GENERAL_REGS), and from there making it treat this case the same as any other where it has to reload to satisfy the constraints of some particular instruction. Given that I know nothing about IRA at this point beyond the little bit I picked up when trying to analyze this problem, that seems scarier than just fixing it in the MIPS backend, but certainly not as scary as adding stuff to split live ranges to IRA. :-) Anyone else have thoughts about the best way to proceed here? -Sandra
Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/11 08:33, Sandra Loosemore wrote: > > I picked up when trying to analyze this problem, that seems scarier than > just fixing it in the MIPS backend, but certainly not as scary as adding > stuff to split live ranges to IRA. :-) Splitting live ranges in IRA is pretty easy as is getting IRA to allocate hard regs for the split ranges. What's hard is getting the costing models properly updated after the range split without rescanning the entire function. My range splitting code works on BBs/EBBs boundaries, but it wouldn't be that hard to add splitting within a BB. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOMXZNAAoJEBRtltQi2kC7HIMH/AtqJol9OpquhnN1VFCI5tyY BC7GeqMeKU0a1Xz/qUONnK9CZghyVM4S6wqRsC5ZsmGjlDN6zjkGTNFNbM6hFxI3 iTkTz0Etf/M+tjmE89Kbyp0tq68UZuZ69UPDBX+cIZJKuzsvnnzjGDYgeUTns5Fw +UqOzQ5PriPqsCJfdG+jjtbgyIIe6X/NChlVn3TjfT/XYuZwsgGK5IDUB7/bX0t2 YCvf/NggXJVcH7419ShiBMTD4zGe9gqYpLfn8yIdL6wQuf2xkaW3UcmmljqUQ6dp Lp0MyBlmtiyzwF0sjkujh0B3IF2k9eXPjQ7m1l7dewfO9yAAEl+euh3ufXO5n/E= =CP28 -END PGP SIGNATURE-
gcc-4.5-20110728 is now available
Snapshot gcc-4.5-20110728 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110728/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 176904 You'll find: gcc-4.5-20110728.tar.bz2 Complete GCC MD5=1104dcd0f8e973f2a186cea955c9c15a SHA1=e74c4b0bd6af079edb3f57ff4405abb3d349bafa Diffs from 4.5-20110721 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Hosting new mirror.
Hi Sergey, On Fri, 22 Jul 2011, Sergey Kutserey wrote: > Hi there! I would like to host a new mirror in US, Missouri, Saint > Louis. I have a server with alot free space and many bandwidth > available. The mirror will have URL like gcc.petsads.us My email > s.kutse...@gmail.com My name is Sergey Kutserey > > Please send me the details on how to setup a new mirror. just go ahead and set up the new mirror and once it's up and running let us know, ideally by sending a patch for http://gcc.gnu.org/mirrors.html that covers your new mirror. Thanks, Gerald
