This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
- From: "wilson at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Jan 2004 23:22:43 -0000
- Subject: [Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
- References: <20040117230657.13722.schwab@suse.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From wilson at specifixinc dot com 2004-01-23 23:22 -------
Subject: Re: PR 13722 candidate fix
On Fri, 2004-01-23 at 00:47, Zack Weinberg wrote:
> Re-revised patch.
I started a bootstrap as soon as I saw the patch. It just failed. I
will try taking a look at this, but I don't know if I will have enough
time to do anything useful.
I did take a look at the patch.
You mention reload nightmares. There is a reload nightmare only if you
fight how reload works. If we allocate an OImode scratch instead of a
DImode scratch, then I think we will always get at least one safe
scratch register. The instruction can use at most 4 registers, 2 for
the register operand, 1 for the address of the memory operand, and
optionally one for the auto-inc operand in the memory operand. In the
worst case, where we have complete overlap between the 4 scratch
registers and the 4 insn registers, it gets more complicated. If we are
doing a load, then we can use the dest register that is loaded last as
the scratch register. If we are doing a store, hmm, I guess in this
case we need a workaround, but this is just one very specific case that
needs a workaround and it is going to be very rare.
Keep in mind that Itanium2 has 4 memory ports. It can do up to 2 loads
and 2 stores per cycle. Using auto-inc addresses instead of a scratch
reg eliminates ILP, and will hurt performance. The TImode stuff perhaps
doesn't occur often enough to worry about, but I think this would
seriously hurt ia64-hpux long double performance. I think we should
consider whether this performance hit is acceptable. It might be
acceptable to get the compiler working again, but at the very least I
think it makes sense to add some ??? comments pointing out that we have
an optimization problem. At least this doesn't affect ia64-linux long
double performance.
SUBREG is valid anywhere where a REG is valid. I see a number of places
where you handle REG but not SUBREG. Also, I see one place where you
assume a value is a REG without checking first. The address of a MEM
could be a SUBREG. The operand to POST_MODIFY could be a SUBREG. The
"register" operand could be a SUBREG. When you check for overlap
between the "register" operand and a MEM, we need to check for SUBREGs.
This problem and the missing REG_INC notes may be enough to explain why
it doesn't work. I'll try adding simple checks for SUBREGs to see if
this problem actually occurs during an Ada bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722