For some reason the REG_DEAD is not the cause of the failure
it is the fact that the SMSed basic-block wasn't mark dirty for
update_life_info that come after it. doing so fixes the failure
even with REG_DEAD is still in that insn. The REG_DEAD note
is correct when we look inter-block so maybe it is still
correct to keep their.
The question is: what is the correct fix for the longer term ?
is it enough to mark the SMSed block dirty? or do we need
also to keep the REG_DEAD correct in each basic-block
separately?
Mostafa Hagog/Haifa/IBM wrote on 16/03/2005 17:17:35:
> Following the discussion in bugzilla I have came to a conclusion
> that the problem is that we copy REG_NOTEs along with the
> instructions. they belong to. This is not correct for some kinds of
> REG_NOTE. The fix is to prevent us from copying the notes in some of
> the cases. I have went over the notes defined in reg-notes.def and
> listed below the notes that (IMO) copying them maybe not correct.
> All the reg-notes that aren't mentioned below either describe a side
> effect on the insn they belong to (so the note is correct for the
> new copy) or they belong to call/jump instructions that we do not
> copy. We use duplicate_insn_chain, which calls
> emit_copy_of_insn_after to do the actual copy, the later copies the
> notes along with the instructions, a possible fix is to pass this
> function a flag to tell her not to copy the below mentioned kind of
> notes when the flag is specified and to act in the normal way if
> not. What do you think ?
>
> REG_NOTE (DEP_TRUE)
> REG_NOTE (DEP_ANTI)
> REG_NOTE (DEP_OUTPUT)
> I suppose we shouldn't care about these because emit_copy_of_insn_after
> doesn't copy LOG_LINKs.
>
> REG_NOTE (DEAD)
> musn't be copied (the cause of the bug)
>
> REG_NOTE (NONNEG)
> REG_NOTE (NO_CONFLICT)
> REG_NOTE (UNUSED)
> mustn't be copied
> describe a fact about other instructions so this
> may change if copied.
>
> REG_NOTE (CC_SETTER)
> REG_NOTE (CC_USER)
> I suppose that using CC0 is possible only in branch instructions
> (correct me if I am wrong)
> and since (at least currently) we aren't copying the
> compare/branch so we shouldn't
> worry about it, I suppose that the correct handling for this (once
> we need it)
> is to copy the pair and update the link respectively.
