This is the mail archive of the gcc-patches@gcc.gnu.org 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] PR middle-end/43631


> 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.

Can we reorganize insn-notes.def so that the 3 classes are clearly separated
(and optionally define a NOTE_INSN_CLASS macro so that we don't need to 
enumerate the notes each time)?

Reading your patch, it apppears that NOTE_INSN_SWITCH_TEXT_SECTIONS is the 
only member of the 1st class and that almost all notes are in the 2nd class 
except for the 2 LOCATION and the 2 EH_REGION recently added notes.

> With this patch I've chosen to maintain the invariant that BB_END must
> be an INSN, and never be a NOTE or BARRIER.

Yes, I think that's the historical design.

> 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.

Slightly annoying, but trumped by the previous requirement I think.

> 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!

Thanks for working on this.  Some nits in the patch:

 - Remove the

    This and the next should be the only functions called to insert an insn
    once delay slots have been filled since only they know how to update a
    SEQUENCE.

from the head comment of functions that are now private to emit-rtl.c.

 - Are there still public functions that cannot be invoked in emit-rtl.c to 
insert insns where there are SEQUENCEs in the stream?  If so, you need to mark 
the ones which can be invoked explicitly with a blurb in the head comment.

-- 
Eric Botcazou


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