This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix stmt folding in the inliner (PR tree-optimization/88444)
- From: Richard Biener <rguenther at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Dec 2018 09:23:59 +0100 (CET)
- Subject: Re: [PATCH] Fix stmt folding in the inliner (PR tree-optimization/88444)
- References: <20181213225909.GC12380@tucnak> <email@example.com>
On Thu, 13 Dec 2018, Jeff Law wrote:
> On 12/13/18 3:59 PM, Jakub Jelinek wrote:
> > Hi!
> > The inliner doesn't want to fold statements immediately, but records them
> > and then fold_marked_statements is meant to fold them when inlining is done.
> > On the following testcase it doesn't fold some of them though.
> > The problem is that it wants to scan only newly added basic blocks (i.e.
> > those created during the inlining), but the way it is written only works if
> > there are no gaps in the basic_block vector. If there are, it can fold
> > stmts only in some of the basic blocks or none of them.
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> > trunk?
> > 2018-12-13 Jakub Jelinek <firstname.lastname@example.org>
> > PR tree-optimization/88444
> > * tree-inline.c (fold_marked_statements): Iterate up to
> > last_basic_block_for_fn rather than n_basic_blocks_for_fn.
> > * gcc.dg/tree-ssa/pr88444.c: New test.
It also looks like it is written in the way to scan BBs because in
older times gsi_for_stmt was O(n). Today we might be able to
simply walk the hash-set and fold contained stmts. Iff we continue
walking stmts we could consider to allow fold_stmt to walk
Anyway, just sth to consider for GCC 10.
Thanks for catching this subtle bug ;)