------- 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 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
