Use-and-clobber insns and REG_DEAD notes
Michael Matz
matz@suse.de
Mon Jul 7 07:00:00 GMT 2003
Hi,
On Sun, 6 Jul 2003, Ulrich Weigand wrote:
Just to be sure, you have a (read) reference to CC, plus an extra clobber
for CC in the insn, yes? Like
parallel[
(set (bla) (plus (reg blubb) (reg CC))
(clobber (reg CC))]
And no explicit set of CC, right?
> There appears to be confusion how such insns are supposed to
> be treated w.r.t. REG_DEAD notes. Should there be one for
> the CC register in such an insn or not? For use-and-set
> patterns it is clear that there will be no REG_DEAD note
> (only the REG_UNUSED note). However, for use-and-clobber
> patterns there is a discrepancy (which causes an assertion
> failure in the scheduler later on):
>
> flow.c generates a REG_DEAD note for that insn
which is correct. A clobbered register implicitely dies in this insn, and
hence can't be used anymore.
> (and a REG_UNUSED note as well).
I think this is incorrect, at least from the big picture. The REG_UNUSED
is only useful for register which could _possibly_ be used later, which is
only true for those which are actually set to some value. Registers which
are clobbered can't have any meaningful use later on, hence they will be
unused by definition. A REG_UNUSED is therefore not needed.
Having said that, this would be the ideal situation, and especially
thinking about REG_NO_CONFLICT blocks and subregs I'm not at all sure
about what things will break if flow.c would be changed to match that
ideal situation ;-|
> However, when some other insn is combined into it, combine.c thinks it
> does not need to distribute the REG_DEAD note into the insn (because
> dead_or_set_p returns true),
Hmm, I'm not sure I understand. Insn X is combined _into_ such a
cc-use-clobber insn Y? To where should the REG_DEAD note (from insn Y) be
distributed. insn X will be deleted if the combining is successful.
And even if flow would behave as described above (not emitting the
REG_UNUSED note), CC would _still_ be dead_or_set_p(). After all it _is_
set (clobbered, and thereby implicitely even dead).
Ciao,
Michael.
More information about the Gcc
mailing list