This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-ra] "#if DENIS"
Denis Chertykov <denisc@overta.ru> writes:
> 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.
What do you think about this ?
Denis.