This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: grokfield miscompiled with -O9
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: grokfield miscompiled with -O9
- From: Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>
- Date: 10 Jan 2000 03:04:32 -0200
- Cc: gcc-patches at gcc dot gnu dot org
- References: <200001060411.XAA24509@onsager.chem.mcgill.ca> <orr9fup2ik.fsf@benta.lsd.ic.unicamp.br> <20000107102904.A1646@cygnus.com> <200001081846.TAA23474@loewis.home.cs.tu-berlin.de> <orzougtk7d.fsf@garnize.lsd.ic.unicamp.br> <20000108123157.B1786@cygnus.com> <orwvpi7eu4.fsf@garnize.lsd.ic.unicamp.br>
On Jan 10, 2000, Alexandre Oliva <oliva@lsd.ic.unicamp.br> wrote:
> On Jan 8, 2000, Richard Henderson <rth@cygnus.com> wrote:
>> But I don't understand the intent of the code I've killed, particularly
>> in context of the other places this function is called. It may be that
>> this code is correct, but that set_nonzero_bits_and_sign_copies shouldn't
>> be using expand_field_assignment.
> How about skipping this simplification just while computing
> nonzero_bits?
> * combine.c (expand_field_assignment): Do not discard SUBREGs
> while computing nonzero_bits.
BTW, the code fragment in i386.c:ix86_expand_setcc got me wondering
why it would be of any help to generate a scratch QI register to store
CC, and whether it had not been coded the way it was because of the
bug fixed (?) in the patch above. So I experimented removing the
scratch register generation, and a bit of benchmarking seems to imply
it doesn't affect performance at all, or, if it does, it improves it a
little bit.
My ``benchmarks'' were to measure the time the stage2 compiler (built
from the patched sources) took to build stage3, and the time taken to
run the bzip2 testsuite:
gcc stage3 build
before:
real 9m20.331s
user 8m49.780s
sys 0m21.940s
after:
real 9m15.239s
user 8m48.690s
sys 0m20.990s
bzip2 test
before:
real 0m2.219s
user 0m2.090s
sys 0m0.100s
after:
real 0m2.207s
user 0m2.040s
sys 0m0.140s
Is the following patch ok to install? (assuming the previous combine.c
patch is ok too)
Index: gcc/ChangeLog
from Alexandre Oliva <oliva@lsd.ic.unicamp.br>
* config/i386/i386.c (ix86_expand_setcc): Do not create a QImode
scratch register.
Index: gcc/config/i386/i386.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.118
diff -u -p -r1.118 i386.c
--- gcc/config/i386/i386.c 2000/01/04 14:44:03 1.118
+++ gcc/config/i386/i386.c 2000/01/10 04:43:40
@@ -4362,12 +4362,7 @@ ix86_expand_setcc (code, unordered, dest
tmp = gen_rtx_STRICT_LOW_PART (VOIDmode, tmp);
}
else if (type == 1)
- {
- if (!cse_not_expected)
- tmp = gen_reg_rtx (QImode);
- else
- tmp = gen_lowpart (QImode, dest);
- }
+ tmp = gen_lowpart (QImode, dest);
emit_insn (gen_rtx_SET (VOIDmode, tmp, ret));
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them