This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix PR29201 - [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
Maxim Kuvyrkov <email@example.com> writes:
> >> The proposed change for extend_bb () merely does two things:
> >> 1. Clear BLOCK_FOR_INSN field of the note that is forced to be outside
> >> the block. This is good because this is right.
> >> 2. Add a comment. This is good unless the comment is wrong.
> > I don't see why we should be relying on having insns that are not in
> > any basic block. I don't think you need to clean that up, but I don't
> > think we should rely on it. So I would prefer to see a change to
> > create_recovery_block that doesn't rely on that. Under that
> > assumption, the change to extend_bb, while probably correct given the
> > way the code works today, is a separate, unrelated, patch.
> I don't see any code that _rely_ on insns outside the blocks. Yes, we
> do check that if some block doesn't have a fallthrough then anything
> between end of that block and the barrier (that necessarily must
> accompany it) is not in any basic block - thit is nothing more than a
> sanity check.
What I mean is: the test for BLOCK_FOR_INSN in your get_barrier
function makes me uncomfortable. It leaves another issue for us to
clean up later. I'd like to fix this problem while minimizing such
> > Yeah, tablejumps are a special case. We could do something like
> > this:
> > barrier = next_nonnote_insn (BB_END (before_recovery));
> > if (LABEL_P (barrier) && JUMP_TABLE_DATA_P (NEXT_INSN (barrier)))
> > barrier = NEXT_INSN (NEXT_INSN (barrier));
> > gcc_assert (BARRIER_P (barrier));
> > Or we could wrap that up in a little function.
> Yes, we could. But I consider your fix too specialized, it hardcodes
> the structure of a table jump into unrelated code.
Yes. We have already hardcoded this structure in other places, e.g.,
expand_gimple_basic_block in cfgexpand.c, rtl_delete_block in
cfgrtl.c, etc. I agree that if we go this route, we should push into
a small function somewhere else, not in haifa-sched.c.
> > I think this code is a bit wacky because it is trying to use the CFG
> > and the straight line insn ordering at the same time.
> This will go away as soon as there will be nothing outside CFG ;)