Re: flow reorg patch

[Richard Henderson <rth at cygnus dot com>]

On Sun, Jan 24, 1999 at 03:05:08AM -0700, Jeffrey A Law wrote:
> Let's try and avoid the inclusion of tree.h in the backend.  It's a
> modularity violation.  One way is to put the decl for the one thing
> you need in multiple .h files.  Another is by using an accessor function.

Ok.

> You define nonlocal_goto_handler_labels in expr.h, shouldn't that have an
> extern in front of it?

Typo.

> Seems rather expensive to rebuild the cfg after threading the prologue and
> epilogue.

Yeah, that was just a quick fix since I've not yet written 
insert_insn_on_edge.  Previously I'd been running flow2 after
thread_p_e so this hadn't been an issue.  But I'd backed that
out so that we wouldn't have quite so many target-specific
issues to deal with.

The correct thing to do is to insert those instructions on the
edge between ENTRY_BLOCK and block 1, and similarly for the exit.

> I see that you've special cased the handling of BASIC_BLOCK notes in unroll.c
> copy_loop_body.  Do we also need special handling of those notes for the code
> in jump.c::duplicate_loop_exit_test?

Perhaps.

> What about when inlining functions?

No, as flow has not been called yet.

> Other places where we copy rtl?

Maybe.

For the PA problem you sent me earlier, I also made flow resistant
to such duplication.  So it is no longer strictly required to care
to prevent such duplication.  But it also makes intermediate dumps
easier to read if we don't duplicate them.

> Isn't the "in_libcall_block" code in find_basic_blocks_* obsolete?  Doesn't
> the code to look up the REG_EH_REGION note on the call insn handle libcalls
> (and other things which can't throw)?

I've not yet incorporated that code.  There are other things I'd like
to do wrt EH -- I may have sent that note just to Andrew but I didn't
think so -- and I thought I'd take care of that all at once after the
bulk of this is delt with.

> !       else if (code != NOTE && code != BARRIER)
> !         prev_call = 0;
> 
> Also notice the slight difference in BARRIER handling in your changes.  I do
> not know if that was intentional or an oversight.

I don't think that old code is right.  If we've seen a barrier,
we're talking about a new block -- there can't be a "prev_call".

> A coding standards nit[s]:

Fixed.


r~