pa reload problem

John David Anglin
Fri Dec 22 09:22:00 GMT 2000

> On Fri, Dec 08, 2000 at 08:07:23PM -0500, John David Anglin wrote:
> > It is my impression that the MEM would pass as a general_operand unless
> > the volatile flag is set.  It will pass GO_IF_LEGITIMATE_ADDRESS.  Thus,
> > the general_operand test doesn't look like it will work.
> The mind boggles.  Why, then, is this strange beast its own insn?

I have done some more testing.

Modifying GO_IF_LEGITIMATE_ADDRESS and adding a general_operand test
to validate_equiv_mem doesn't look like it will work.  The fundamental
problem is that the MEM must pass the GO_IF_LEGITIMATE_ADDRESS test during
reload.  However, this is when we would like the UNSPEC to fail the
general_operand test.

Preventing the substitution of equivalent MEMs increases register pressure. 
Thus, it is desirable to allow substitutions where possible.  On the other
hand, the PA instruction can't handle all substitution possibilities.
Thus, even if all the different insns that handle MEMs in one way or
another were combined into a single insn, reload could still produce
something that wouldn't work.

For a given mode, has several different insns that for example
load memory to a register.  These exist as different insns because
the predicates (and code) differ.  Thus, it is not possible to substitute
the MEM from one insn into another.

I was able to modify print_operand to handle the UNSPEC beast and delete
the `ldw RT' insns for loading a PIC address.  However, I am not certain
that I can work all the insns into a single insn.  I am most concerned
about the index insns `{ldwx|ldw}'.

The simplest solution that I can think of is not to allow equivalent
MEMs on the PA at all (DONT_ALLOW_EQUIV_MEM?).  Since the problem doesn't
seem to happen that frequently given the number of registers available,
possibly this this is a reasonable approach.  What do you think?

J. David Anglin                        
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

More information about the Gcc-bugs mailing list