------- Comment #7 from wilson at tuliptree dot org 2005-11-09 21:07 -------
Subject: Re: [3.4/4.0/4.1 regression] amd64
register spill error with -fschedule-insns
On Wed, 2005-11-09 at 07:27, uros at kss-loka dot si wrote:
> (BTW: I have added Jim Wilson to CC of this bug as he is current maintaine of
> insn scheduling pass code. Perhaps he has some ideas on how to solve this
> problem.)
Vlad's name really should be first in the list, as he is the only one of
the 4 listed people that is actively working on the scheduler.
This problem only shows up when the -fschedule-insns option is used.
The x86 port deliberately disables this by default for good reasons.
One possible solution is to add hooks to the x86 backend that emit an
error when a user specifies the -fschedule-insns option, since it isn't
expected to work, and if it did work, it would more likely than not
result in worse code. I think this is the best short term option.
Another possible solution is to modify the strlenqi_rex_1 pattern to use
explicit hard registers instead of constraints that specify one
register. There is little point in trying to register allocate a
pattern when there is only one possible register that can be used here.
Using a hard register would expose the dependencies to the scheduler,
preventing the scheduler from performing bad optimizations. The
downside here is that use of hard registers may confuse some
optimization passes, or expose limitations in some optimization passes,
resulting in some performance loss. Also, you will have to find and fix
all existing patterns which have this problem. Doing this will be error
prone, and may cause additional problems, and/or may result in an
incomplete fix if some patterns are missed. I doubt that this is worth
the effort.
As for a scheduler fix, we could perhaps test SMALL_REGISTER_CLASSES,
and if defined, then make all insns that use a hard register into a
scheduling barrier (e.g. a call to flush_pending_lists). Most all
targets that define SMALL_REGISTER_CLASSES already disables the first
scheduling pass, so this probably won't break anything. This should be
verified. This is going to severely limit the optimizations that sched1
can perform, which may make it pointless, but at least then the
-fschedule-insns option should work for x86.
Since it was changes to SCHED_GROUP handling that exposed this problem,
perhaps the SCHED_GROUP handling code can be conditional on
SMALL_REGISTER_CLASSES. For instance, maybe we can put the insns
loading parameters into registers into the SCHED_GROUP for
SMALL_REGISTER_CLASSES targets. This would prevent moving such insns
during sched1. This would mean adding code like the existing
in_post_call_group_p stuff, except for insns before a call instead of
insns after a call. I think this is the best long term solution.
As for a register allocator fix, we could extend the RA to be able to
spill and reload hard registers, but the resulting code in this case
would be so bad that I see no point in even trying.
Since end users will gain little benefit from being able to run the
sched1 pass on x86 code, I don't think this is a serious problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
