------- Comment #6 from dje at gcc dot gnu dot org 2007-06-13 20:00 -------
>From IRC:
see.c:2732 makes a copy of an insn and then hacks on it with validate_change
(and it's close relatives). This copy has a basic_block, even though it is not
in the insn stream, as well as the same insn_uid as the old insn.
zadeck This is very bad for df. df assumes that insns have a null block until
they are inserted into the insn stream and it also uses the insn_uid as the
index into tables for the side info. I can fix part of the problem by nulling
out the bb for the clone, but i need to give it a shiney new uid (or else use
some properly supported function to make a copy of an insn.
This is very bad for df. df assumes that insns have a null block until they
are inserted into the insn stream and it also uses the insn_uid as the index
into tables for the side info. I can fix part of the problem by nulling out
the bb for the clone, but i need to give it a shiney new uid (or else use some
properly supported function to make a copy of an insn.
it links the copy into the insn chain by hand
better would be to skip the make_insn_raw, and just call emit_insn_before at
the appropriate moment
that is, copy the pattern, not the whole insn
and pass the pattern to emit_insn_before
it leaves the 2 insn sequence hanging in mid air until later in the pass it may
or may not replace the old insn with the new sequence
that's why god invented start_sequence/end_sequence--so that you can build and
handle sequences of insns
--
dje at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
