This is the mail archive of the gcc@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: [tree-ssa] Fix problem with loop notes emitted by targets


Hello,

>  >some targets (s390, maybe other) produce loops when expanding
>  >builtins; this causes problems as create_loop_notes does not like
>  >the notes created by them.  This patch makes the functions that expand
>  >loops work without creating the notes.  It also removes
>  >NOTE_INSN_LOOP_CONT, since it is not produced anywhere.
>  >
>  >Bootstrapped and regtested on i686, bootstrap on s390 in progress.
>  >
>  >	* cfglayout.c (duplicate_insn_chain): Don't handle NOTE_INSN_LOOP_CONT.
>  >	* cfgrtl.c (rtl_delete_block): Ditto.
>  >	* final.c (final_scan_insn): Ditto.
>  >	* jump.c (squeeze_notes): Ditto.
>  >	* loop.c (find_and_verify_loops, for_each_insn_in_loop): Ditto.
>  >	* unroll.c (copy_loop_body): Ditto.
>  >	* rtl.c (note_insn_name): Remove NOTE_INSN_LOOP_CONT.
>  >	* rtl.h (enum insn_note): Ditto.
>  >	* stmt.c (expand_start_loop, expand_loop_continue_here,
>  >	expand_end_loop): Don't create loop notes.
> Rather than removing LOOP_CONT notes, leave them unused.  We can remove them
> when we merge with the mainline.  Removing them now just adds to the headaches
> when we merge from the mainline.
> 
> It's also the case that if we get to a point where we want to merge to the
> mainline, but don't have a new RTL loop optimizer, then we'll probably
> be stuck trying to rewrite LOOP_CONT notes since they're reasonably
> important to the old loop optimizer.

this takes me to my favourite point: what about the loop optimizer?
Tree-ssa cfg stuff is now in reasonable shape, so I would like to begin
with getting rid of the old one. This obviously is a work for a
subbranch, since it will get some time to make it work without
regressions.  Pop Sébastian will probably be creating a LNO branch for
his loop optimization related stuff, right?  We could either use the
same branch for both, or use separated branches.

I would slightly prefer the later, since it would make evaluation of the
changes easier and also the works seem to be reasonably independent -- I
plan to focus on replacing the rtl stuff and on creating means to
communicate results of tree-level analyses to the rtl level, while I
assume Pop's work will be more tree-level oriented.  Of course the
drawback is the chance of duplicating some stuff & creating conflicts.

Opinions?

Zdenek


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