This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Fix problem with loop notes emitted by targets
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: law at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org,pop at gauvain dot u-strasbg dot fr
- Date: Wed, 17 Dec 2003 11:39:11 +0100
- Subject: Re: [tree-ssa] Fix problem with loop notes emitted by targets
- References: <20031206222847.GA23400@atrey.karlin.mff.cuni.cz> <200312170543.hBH5h91e003187@speedy.slc.redhat.com>
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