This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Avoid creating unbounded complexity debug insns in valtrack (PR debug/77844, take 2)
On Wed, Dec 14, 2016 at 09:34:44AM +0100, Jakub Jelinek wrote:
> Here is updated patch that does that. I had to change the combiner
> in a couple of places, because combiner is very unhappy if new instructions
> (with uids above the highest) are inserted into the insn stream,
> e.g. FOR_EACH_LOG_LINK (link, temp_insn) for DEBUG_INSN temp_insn
> will then crash. But given that DEBUG_INSNs never have non-NULL LOG_LINKS,
> I think we can just avoid using LOG_LINKS or INSN_COST on DEBUG_INSNs
> and allow new DEBUG_INSNs be inserted into the stream (but not regular
> insns - normally combine just reuses INSN_UID of the insns it is replacing).
Could you do a gcc_checking_assert (INSN_UID (INSN) <= max_uid_known)
in the LOG_LINKS and INSN_COST defines? It is hard to check if you
caught every use.
> @@ -2275,7 +2275,7 @@ cant_combine_insn_p (rtx_insn *insn)
> /* If this isn't really an insn, we can't do anything.
> This can occur when flow deletes an insn that it has merged into an
> auto-increment address. */
> - if (! INSN_P (insn))
> + if (! NONDEBUG_INSN_P (insn))
> return 1;
Please get rid of the extra space (and thanks for the other formatting
fixes, little by little :-) )
Looks fine otherwise. Thanks,
Segher