This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reload patch version 3


At 15:15 25.08.98 , Bernd Schmidt wrote:
>Here is an updated version of the reload patch I sent in about a year ago.
>Yesterday I updated it so that it patches cleanly into egcs-980816.
>
>Remarks:
>This patch changes the register allocators, global and stupid, to build a
>chain of "insn_chain" structures that describes all instructions that reload
>will have to look at. The insn_chain structure contains information about the
>lifetime of pseudo and hard registers, and it is utilized by reload to be
>more selective about spilling registers. Without this patch, reload selects
>hard registers to be spilled globally, and throws out all pseudos that are
>allocated to these. With the patch, it only spills pseudos that are live
>during an insn that needs additional reload registers. The amount of spilling
>is much reduced on a register-starved machine like the i386, which leads both
>to better code quality and smaller stack frames.
>
>It is now possible to safely spill hard registers that are explicitly used,
>both on SMALL_REGISTER_CLASSES and non-SMALL_REGISTER_CLASSES machines. On
>S_R_C machines it no longer risks silently generating incorrect code for
>either regparam calls or for incorrect asm statements. In fact, it is _very_
>unforgiving about incorrect asm: it will always bomb out with a spill failure
>if one is found that tries to clobber a register that it also uses as an
>operand. You won't get very far trying to compile a kernel with this... at
>least unless you apply the patch which I'm going to send to linux-kernel
>later.
>
>The patch also throws out two kludges found in reload: the avoid_return_reg
>and reload_address_base_reg_class hacks. They are no longer necessary.
>
>Possible problems:
> - I threw out the code in local-alloc.c to handle SCRATCHes. I no longer
>   remember exactly why - most likely I found that it would have caused
>   some additional effort in reload. Since reload can handle SCRATCHes
without
>   the help of local-alloc, I don't quite see the point of having two pieces
>   of code that do the same thing. If someone has a compelling reason I'll
>   look at that again.
> - I deleted the code that handles the case when a caller-save would require
>   a spill register. I don't see an easy way to handle that case in the new
>   situation, and instead I disable caller-saves when such a situation would
>   occur. I don't know whether this causes suboptimal code to be generated on
>   some machines - feedback is appreciated here.
> - Likewise, reorg.c makes an assumption that is now invalid: that all spill
>   registers are dead at basic block boundaries. This is no longer true, and
>   I commented out the relevant piece of code.
> - While the new reload pass improves code on the i386 compared to the old
>   one, I think the heuristics for selecting which registers to spill are by
>   no means optimal yet.
> - The fact that it is unforgiving about illegal asm statements leads to
>   problems for one class of asms: those which access the i387 register
stack.
>   Please read the comment at the top of reg-stack.c, it _tells_ you to write
>   incorrect asm statements. I've put in a gross hack to try and avoid the
>   problem, but most likely this isn't correct yet (reg-stack could stand
>   a rewrite as well). The only problems I've noticed with the patch so far
>   is a maths test that failed in a glibc-2.0.95 build.
> - Unfortunately I had to disable the unwind information in i386.h. While
>   building libgcc2.a, there is one function in which some builtin eh magic
>   is exercised, and it causes flow.c to build incorrect hard register life
>   information (it thinks ecx is live throughout most of the function, and
>   aborts because it can't reload a variable count shift instruction). That
>   probably needs some fixes to flow.c.
> - Reload has become rather slow, but there is probably room for
optimization.
>   I have so far concentrated on trying to get it to generate correct code.
> - I think REG_NO_CONFLICT blocks aren't handled properly.
>
>Test results (i586-linux; glibc-2.0.95):
> - No comparison failures while bootstrapping. 
> - No regressions in the test suite; gcc.dg/clobbers.c is fixed now.
> - glibc-2.0.95 builds, and mostly passes make check, only one maths test
>   fails.
>(actually, the glibc tests were done with a slightly different patch - this
>one has an additional fix in stupid.c. I hope that this fix didn't break
>anything.)

FYI, I just tried to bootstrap the egcs release branch on
powerpc-unknown-linux-gnu (2.1.118/glibc-2.0.95) and it failed during
stage1 with the following error:

stage1/xgcc -Bstage1/ -c  -DIN_GCC    -O2 -g -O2  -DHAVE_CONFIG_H -DHAIFA
 -I. -I../../../egcs/gcc -I../../../egcs/gcc/config ../
../../egcs/gcc/global.c
stage1/xgcc -Bstage1/ -c  -DIN_GCC    -O2 -g -O2  -DHAVE_CONFIG_H -DHAIFA
 -I. -I../../../egcs/gcc -I../../../egcs/gcc/config ../
../../egcs/gcc/reload.c
../../../egcs/gcc/caller-save.c:654: Internal compiler error in function
insert_save_restore
make[2]: *** [reload.o] Error 1
make[2]: Leaving directory `/home/fsirl/obj/cvs11/gcc'
make[1]: *** [bootstrap-lean] Error 2
make[1]: Leaving directory `/home/fsirl/obj/cvs11/gcc'
make: *** [bootstrap-lean] Error 2

Franz.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]