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] Fix ifcvt (PR rtl-optimization/58668)


On Wed, Dec 18, 2013 at 11:21:52PM +0100, Steven Bosscher wrote:
> On Wednesday, December 18, 2013, Jakub Jelinek wrote:
> > As discussed in the PR, this testcase ICEs on arm, because ifcvt
> > is relying on active instruction counts from various routines
> > (count_bb_insns, flow_find_cross_jump and flow_find_head_matching_sequence),
> > but each of those routines have different view of what counts as
> > active insns.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
> > and tested on the testcase using cross to arm.  Ok for trunk?
> >
> > 2013-12-18  Jakub Jelinek  <>
> >         PR rtl-optimization/58668
> >         * cfgcleanup.c (flow_find_cross_jump): Don't count
> >         any jumps if dir_p is NULL.  Remove p1 variable and make USE/CLOBBER
> >         check consistent with other places.
> >         (flow_find_head_matching_sequence): Don't count USE or CLOBBER insns.
> >         (try_head_merge_bb): Adjust for the flow_find_head_matching_sequence
> >         counting change.
> >         * ifcvt.c (count_bb_insns): Don't count USE or CLOBBER insns.
> 
> Why not use active_insn_p instead of hand-checks for USE and CLOBBER insns?

Because it brings in the JUMP_TABLE_DATA mess into the picture?  Some of the
places already guard it with INSN_P and similar checks and do more things
than just counting the insns under those conditionals, so in other places
one can't just use say prev_active_insn or next_active_insn anyway, the insn
type has to be checked then and thus active_insn_p would become just a fancy
way of checking for USE/CLOBBER.

	Jakub


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