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

[Denis Chertykov <denisc at overta dot ru>]

Michael Matz <matz@suse.de> writes:

> Hi,
> 
> On Thu, 3 Jul 2003, Denis Chertykov wrote:
> 
> > Why we can't use both variants from "#if DENIS" condition ?
> > They will complete each other.
> 
> Maybe, I wasn't completely sure.  Let's see:
> 
> In insert_stores() this looks like:
> 
> > - #if DENIS
> >   		  if ((web->pattern || copy_insn_p (insn, NULL, NULL))
> >   		      && ra_validate_change (insn, DF_REF_LOC (info.defs[n]),
> >   					     slot, 0))
> > ! #else
> >   			ra_emit_move_insn (source, slot);
> > --- 785,818 ----
> >   		  if ((web->pattern || copy_insn_p (insn, NULL, NULL))
> >   		      && ra_validate_change (insn, DF_REF_LOC (info.defs[n]),
> >   					     slot, 0))
> > ! 		  else
> > ! 		    if ((DF_REF_FLAGS (info.defs[n]) & DF_REF_ALREADY_SPILLED)
> > ! 			|| (! (rdef && RA_REF_ADDRESS_P (rdef))
> > ! 			    && validate_change (insn,
> > ! 						DF_REF_LOC (info.defs[n]),
> > ! 						slot, 0)))
> 
> This won't work in all cases.  Some defs might already have added a spill
> in rewrite_program (i.e. where the loads are emitted), due to
> read-modify-write webs.  I.e. before adding a spill for defs[n] the flags
> must be checked in every case to not contain DF_REF_ALREADY_SPILLED.
> 
> Your other condition (web->pattern being set): If web-pattern is set, it
> might be for instance a constant.  Wouldn't that mean, that the
> ra_validate_change() would sometime try to emit such insns:
> (set (const 1) (bla)) ?  Recognizing them would of course fail, but why
> trying it at all?

You are wrong. I have checked "is this a def for rematerializable
value". I don't  want to replace value by web->pattern.
I will replace it by spill slot.

> 
> And finally your third condition (copy_insn_p): isn't that subsumed by my
> condition anyway?  My condition basically does this: if this def wasn't
> yet spilled, and this def is not part of an address, then try to replace
> it inline.  If I see it right, this is trivially true for copy
> instructions, so in those cases the condition is equivalent.  Or do I
> overlook anything?

Yes. Rematerialization.

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

Results are different because in my case p86' is a rematerializable
value. And this value will be rematerialized by delayed remat in next
pass if it don't got a color in current pass.


Denis.
PS: You can compile the following example with my patch and without it.

Example: fetch.c 

typedef unsigned int size_t;

typedef long long gcov_type;

static int
__fetch_gcov_type (dest, source, bytes)
     gcov_type *dest;
     char *source;
     size_t bytes;
{
  gcov_type value = 0;
  int i;

  for (i = bytes - 1; (size_t) i > (sizeof (*dest) - 1); i--)
    if (source[i] & ((size_t) i == (bytes - 1) ? 127 : 255 ))
      return 1;

  for (; i >= 0; i--)
    value = value * 256 + (source[i]
			   & ((size_t)i == (bytes - 1) ? 127 : 255));

  if ((source[bytes - 1] & 128) && (value > 0))
    value = - value;

  *dest = value;
  return 0;
}