This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload


------- 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


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