Re: help with address reload

[Bill Currie <bcurrie at tssc dot co dot nz>]

Joern Rennecke wrote:
> > (set (reg:SI xx)
> >      (mem:SI (lo_sum:SI (high:SI (symbol_ref "sym))
> >                         (symbol_ref "sym))))
> 
> Presumably, you have a GO_IF_LEGITIMATE_ADDRESS definition that allows
> this address.  If that is the case, I suggest fixing that.

No, it rejects it (I think), second last `else if'

#define CONSTANT_ADDRESS_P(X)   \
  (GET_CODE (X) == LABEL_REF || GET_CODE (X) == SYMBOL_REF		\
   || GET_CODE (X) == CONST_INT || GET_CODE (X) == CONST		\
   || GET_CODE (X) == HIGH)

#define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR)		\
{ if (GET_CODE (X) == REG)				\
    { if (REG_OK_FOR_BASE_P (X)) goto ADDR; }		\
  else if (GET_CODE (X) == PLUS)			\
    {							\
      if (GET_CODE (XEXP (X, 0)) == REG			\
	  && REG_OK_FOR_BASE_P (XEXP (X, 0)))		\
	{						\
	  if (GET_CODE (XEXP (X, 1)) == CONST_INT	\
	      && INTVAL (XEXP (X, 1)) >= -0x8000	\
	      && INTVAL (XEXP (X, 1)) < 0x8000		\
	      && (INTVAL (XEXP (X, 1)) & (GET_MODE_SIZE (MODE) - 1)) == 0) \
	    goto ADDR;					\
	}						\
      else if (GET_CODE (XEXP (X, 1)) == REG		\
	  && REG_OK_FOR_BASE_P (XEXP (X, 1)))		\
	{						\
	  if (GET_CODE (XEXP (X, 0)) == CONST_INT	\
	      && INTVAL (XEXP (X, 0)) >= -0x8000	\
	      && INTVAL (XEXP (X, 0)) < 0x8000		\
	      && (INTVAL (XEXP (X, 0)) & (GET_MODE_SIZE (MODE) - 1)) == 0) \
	    goto ADDR;					\
	}						\
    }							\
  else if (GET_CODE (X) == LO_SUM &&			\
	   GET_CODE (XEXP (X, 0)) == REG &&		\
	   CONSTANT_ADDRESS_P (XEXP (X, 1)))		\
    goto ADDR;						\
  else if (CONSTANT_ADDRESS_P (X))			\
    goto ADDR;						\
}


> > I've figured out that I may need to define LEGITIMIZE_RELOAD_ADDRESS,
> > which I did to:
> 
> It shouldn't be necessary to define LEGITIMIZE_RELOAD_ADDRESS to get
> correct code.

Well, in the end, I got it to work with LEGITIMIZE_RELOAD_ADDRESS,
though it doesn't quite produce optimal code: it winds up loading the
whole address into a register and then dereferenceing the register
unindexed.  Not what I was after.  I'm getting

        orh [bb_head]@h,%r0,%r28
        or [bb_head]@l,%r28,%r28
        ld.l 0(%r28),%r14

when I shoul be getting
        orh [bb_head]@h,%r0,%r28
        ld.l bb_head@l(%r28),%r14

which I usually do, but there's the one instance of the suboptimal
version which I beleive is caused by reload.

> > However, this gives me an abort (I've read the comment at the abort, so
> > I know I'm doing something wrong).
> 
> There is more than one abort in the gcc sources, therefore the above
> sentence isn't helpful in describing your problem.

Yes, sorry about that.  Line 484 of reload.c (in my copy)
  /* This case isn't valid, so fail.  Reload is allowed to use the same
     register for RELOAD_FOR_INPUT_ADDRESS and RELOAD_FOR_INPUT reloads,
but
     in the case of a secondary register, we actually need two different
     registers for correct code.  We fail here to prevent the
possibility of
     silently generating incorrect code later.

     The convention is that secondary input reloads are valid only if
the
     secondary_class is different from class.  If you have such a case,
you
     can not use secondary reloads, you must work around the problem
some
     other way.

     Allow this when MODE is not reload_mode and assume that the
generated
     code handles this case (it does on the Alpha, which is the only
place
     this currently happens).  */

  if (in_p && class == reload_class && mode == reload_mode)
    abort ();

I got around this be defining a SCRATCH_REGS class (and using it) and
ran into some more problems, see below.

> No, register 31 is a fixed register, therefore it can only be used by
> explicit code in the machine description, i.e. hard-coding it in the
> output templates.

Yes, I found that out the hard way.  I changed my SCRATCH_REGS class to
cover regs 4-30 and this got things working.

> > Actually, shouldn't reload detect (lo_sum (high ...) ...) on it's own
> > and fix it by itself?
> 
> That depends on the definition of GO_IF_LEGITIMATE_ADDRESS.

Well, my definition of it is above.  Is there anything obviously wrong
in it?  I can't see it.

> > BTW, about 18 months ago, I sent in assignment forms to the FSF for my
> > work on GNU Pascal.  Are they still valid and can they apply to gcc in
> > general?  I don't think they have any email addresses on them, if they
> 
> That depends on the wording used on the form.  E.g. you you have specifically
> assigned rights for only GNU pascal, the assignment is not general enough.

Thanks, I think it may have been explicitly for GNU Pascal, but I'm not
sure.

Bill
-- 
Leave others their otherness