This is the mail archive of the
mailing list for the GCC project.
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
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.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com