This is the mail archive of the gcc-patches@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]

Re: [PATCH] Reload fixes for EXTRA_MEMORY_CONSTRAINT problems


Joern Rennecke wrote:

> No, more specifically, it has to be the exact value in reload_in_reg
> of a reload for the same instruction that you would otherwise need a USE
> for.  This is roughly equivalent with it being the toplevel input object
> being handled by an input or input-output reload (of course, it might
> still be a subexpression in some other reload at the same time).
> If reload_out_reg of a reload is set to a pseudo, that obviates the need
> for a CLOBBER of that pseudo in respect of this instruction.

OK, thanks for the explanation.

> There are two things wrong here.  First, we don't need the
> optional reload, because we already have a mandatory reload.
> you can use find_replacement to check for this case before
> the check if we want to make an optional reload, e.g.:

But find_replacement only works if find_reloads was called with 
the 'replace' parameter set.  This would mean that during the
calls of find_reloads from calculate_needs_all_insns, we would
always get the incorrect optional reloads, and only in the final
find_reloads pass would they disappear, if I understand things
correctly.  Is that supposed to work?

(B.t.w. I'm not quite sure what the point of the replace parameter
is in the first place; it would appear it saves only a negligable
amount of work ...)

> Second, there are cases where we do need the optional reload (or a USE,
> but that would be less efficient).  E.g. the Motorola 68020 has
> memory-indirect addressing, and a lea instruction that can make use of it.
> Hence, address reloading wouldn't eliminate a single-level memory reference.
> The find_replacements check above will then come up blank, so we'll
> proceed to do an optional reload - which is fine - however, we'll do it in
> the wrong mode.  So, yes, we should use Pmode then.
> Or we could look at the actual mode of the operand - since we are handling
> erstwhile pseudo register references, there should never be VOIDmode there.	

I'm not quite sure under what circumstances the actual mode of an
address operand could be different from Pmode.  In any case, do you
think something like the patch below would be reasonable?

Index: reload.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.198
diff -c -p -r1.198 reload.c
*** reload.c	20 Nov 2002 17:05:08 -0000	1.198
--- reload.c	24 Nov 2002 19:35:24 -0000
*************** find_reloads (insn, replace, ind_levels,
*** 2684,2689 ****
--- 2684,2697 ----
  
  	  recog_data.operand[i] = *recog_data.operand_loc[i];
  	  substed_operand[i] = recog_data.operand[i];
+ 
+ 	  /* If we generate a reload later on, we should not use the mode
+ 	     specified in the machine description, because this is interpreted
+ 	     differently for address operands.  Use the operand's existing
+ 	     mode or Pmode instead.  */
+ 	  operand_mode[i] = GET_MODE (recog_data.operand[i]);
+ 	  if (operand_mode[i] == VOIDmode)
+ 	    operand_mode[i] = Pmode;
  	}
        else if (code == MEM)
  	{


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de


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