This is the mail archive of the
mailing list for the GCC project.
Re: [patch] PR middle-end/43631
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Tue, 9 Apr 2013 18:53:30 +0200
- Subject: Re: [patch] PR middle-end/43631
- References: <CABu31nPmRrkRfqjbYq-kfqHgjVxiYuvG9wvB+Z3sw_CgPd+GQw at mail dot gmail dot com>
Also bootstrapped&tested on ia64-unknown-linux-gnu now.
On Sun, Apr 7, 2013 at 12:40 AM, Steven Bosscher wrote:
> In this PR43631, var-tracking notes are inserted on basic block
> boundaries and BB_HEAD/BB_END end up pointing to these notes. This
> breaks verify_flow_info.
> The problem is actually bigger than just the var-tracking notes. The
> general problem is that there are no rules for whether or not notes
> are part of a basic block or not. Some notes never appear inside a
> basic block, some notes always must appear inside a basic block, and
> some can appear virtually anywhere.
> With this patch I've chosen to maintain the invariant that BB_END must
> be an INSN, and never be a NOTE or BARRIER. The result is that
> NOTE_INSN_EH_REGION_BEG notes can be inside a basic block while the
> pairing NOTE_INSN_EH_REGION_END is outside the basic block. I don't
> think this is a problem: The same thing already happens with jump
> table data, barriers, etc.
> The nice thing is that with this patch, *finally* I have
> verify_flow_info pass after var-tracking. That's important because
> officially the CFG is freed after this pass (pass_free_cfg runs after
> pass_variable_tracking) but because verify_flow_info didn't pass after
> var-tracking the CFG was already invalidated before it was freed
> (BB_HEAD and BB_END would be incorrect). That has the effect that some
> of the machine-reorg passes that use the CFG never really had a
> correct CFG at all!
> With this patch and a hack to call compute_bb_for_insn, I now can call
> verify_flow_info in every pass up to final for the i386 port :-)
> Bootstrapped&tested on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu.
> OK for trunk?