Re: [new-ra] "#if DENIS"

[Denis Chertykov <denisc at overta dot ru>]

Michael Matz <matz@suse.de> writes:

> > My code will transform
> > ;; Begin of basic block 0
> >   3	p59 <= [h16]:SI
> >
> > to
> >   3	p86' <= [h16]:SI
> >
> > But, your to
> > ;; Begin of basic block 0
> >   3	p59 <= [h16]:SI
> >   203`	p86' <= p59
> 
> Yes.  I think that is because our different view on pseudo webs.  I think
> of them as being stack slots already,

Yes, yes.
May be better try to got some statistics about this situation.
If many spill pseudos will be colored then I have a more realistic
view. If not then you. It's also very dependent from cpu arch.
All my favorite architectures (ports) are very strictedand and I have
based my point of view on it.
IMHO: ix86 also has a significant restrictions. Has a very small classes.


> and hence I can't do the
> transformation you do, because that would mean the insn has two memory
> references (the load from [h16] and the store to p86').  This
> transformation _is_ tried in my code, but rejected because an invalid
> instruction would result in case the pseudo web can not be colored later,
> which would mean a reload.  But that's the same in your version.  In the
> insn "3   p86' <= [h16]:SI" you also could have two memory accesses, if
> p86 is not colored.

No.
Current allocator generate slack slots only in one place.
It's assign_stack_slots_1:2527

The following fragment part of assign_stack_slots_1:

	    if (ra_validate_change (insn, DF_REF_LOC (refs[j]), source, 0))
	      {
		df_insn_modify (df, bb, insn);
		bitmap_set_bit (ra_modified_insns, INSN_UID (insn));
		bitmap_set_bit (last_changed_insns, INSN_UID (insn));
	      }
	    else
	      {
		if (i == 0) /* Insn for use.  */
		  ra_emit_move_insn (copy_rtx (target), source);
		else
		  ra_emit_move_insn (source, copy_rtx (target));
	      }


The code check insn validity and reject invalid insns.
If insns invalid then the following sequence will be generated:
   3	p86' <= [h16]:SI
   203` [stack-slot] <= p86'

In this case allocator will have additional pass for colorize p86.


> With your patch the code for the fetch.c example is clearly better, but
> I'm not sure about more complex examples which could require reloads.  How
> do you think this is handled?

assign_stack_slots_1 is a single place where stack slots allocated and
placed to insns. (I hope :)

Any reloads must not happened because assign_stack_slots_1 will
check insn validity and generate additional move if required.
It's similar to reload, but it's not a reload it's part of remat/spilling.
IMHO: even more ra-spilling must substitute reload.

Denis.