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]

Re: Reload patch v4




On Tue, 6 Oct 1998, Jeffrey A Law wrote:

> 
>   > Are you sure about this?  It should be perfectly legal to inherit across
>   > a basic block boundary, unless there's a CODE_LABEL at the start of the
>   > second basic block.
> I was fairly sure.  Though I hadn't actually looked at the code.
> 
> Yes, in theory, you can inherit across a bb boundary if there's no label --
> effectively it means we're inheriting within extended basic blocks.
> 
> And as you mention, this could cause problems with the code to avoid spilling
> psuedos in hard regs in blocks which don't need the hard regs for spill regs.
> This is worrisome.
>
> Can you look into how/why this is safe

I believe it is safe because of the following piece of code in
forget_old_reloads_1.  Note the comment at the top, it seems to describe
the scenario we are discussing.

      /* Storing into a spilled-reg invalidates its contents.
	 This can happen if a block-local pseudo is allocated to that reg
	 and it wasn't spilled because this block's total need is 0.
	 Then some insn might have an optional reload and use this reg.  */
      for (i = 0; i < nr; i++)
	/* But don't do this if the reg actually serves as an output
	   reload reg in the current instruction.  */
	if (n_reloads == 0
	    || ! TEST_HARD_REG_BIT (reg_is_output_reload, regno + i))
	  CLEAR_HARD_REG_BIT (reg_reloaded_valid, regno + i);


> While we don't have the exact same problem with localized spilling, I do think
> we have a closely related problem.  We need to look into this further.

The problem is almost identical.  The only difference as far as the
inheritance code is concerned is that there are more cases where the
above code might be run, because the case where a pseudo is not spilled
although it is allocated to one of the spill registers will become the
rule rather than the exception.  However, nowhere in the inheritance code
does the _reason_ why this happens seem to make any difference, so if the
above piece of code is sufficient for the current situation, it ought to
work just fine with local spilling in place as well.
I freely admit that I don't understand all of the inheritance code.  Maybe
someone who knows it better could comment?

>   > Maybe because of this (from eliminate_regs):
>   > 
>   >         /* If SET_DEST changed from a REG to a MEM and INSN is an insn,
>   >            write a CLOBBER insn.  */
>   >         if (GET_CODE (SET_DEST (x)) == REG && GET_CODE (new0) == MEM
>   >             && insn != 0 && GET_CODE (insn) != EXPR_LIST
>   >             && GET_CODE (insn) != INSN_LIST)
>   >           emit_insn_after (gen_rtx_CLOBBER (VOIDmode, SET_DEST (x)), insn);
>   > 
>   > This appears to emit CLOBBERs for some pseudos that didn't get hard registe  > rs.
>   > I think I remember that there was code in reload.c that did something simil
>   > ar, but I can't find it right now.
> Could be.  I don't know.  I just know I saw pseudos in that function :-)

> I think we need to find out under what conditions we can get a pseudo into
> that function and determine how that interacts with localized spilling and
> inheritance.

I just noticed that there might be another reason.  From reload_as_needed:

	  /* Any previously reloaded spilled pseudo reg, stored in this insn,
	     is no longer validly lying around to save a future reload.
	     Note that this does not detect pseudos that were reloaded
	     for this insn in order to be stored in
	     (obeying register constraints).  That is correct; such reload
	     registers ARE still valid.  */
	  note_stores (oldpat, forget_old_reloads_1);

This is calling note_stores on the old pattern which we had before register
elimination.  That one might contain pseudos which did not get a hard
register.

Bernd


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