This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix PR29201 - [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3

Maxim Kuvyrkov <> 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 ;)

Yes, exactly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]