IVOPT improvement patch

Jan Hubicka hubicka@ucw.cz
Tue May 11 09:48:00 GMT 2010


> On Tue, May 11, 2010 at 8:35 AM, Xinliang David Li <davidxl@google.com> wrote:
> > Hi, IVOPT has been one of the main area of complaints from gcc users
> > and it is often shutdown or user is forced to use inline assembly to
> > write key kernel loops. The following (resulting from the
> > investigation of many user complaints) summarize some of the key
> > problems:
> >
> > 1) Too many induction variables are used and advanced addressing mode
> > is not fully taken advantage of. On latest Intel CPU, the increased
> > loop size (due to iv updates) can have very large negative impact on
> > performance, e.g, when LSD and uop macro fusion get blocked. The root
> > cause of the problem is not at the cost model used in IVOPT, but in
> > the algorithm in finding the 'optimal' assignment from iv candidates
> > to uses.
> >
> > 2) Profile information is not used in cost estimation (e.g. computing
> > cost of loop variants)
> >
> > 3) For replaced IV (original) that are only live out of the loop (i.e.
> > there are no uses inside loop), the rewrite of the IV occurs inside
> > the loop which usually results in code more expensive than the
> > original iv update statement -- and it is very difficult for later
> > phases to sink down the computation outside the loop (see PR31792).
> > The right solution is to materialize/rewrite such ivs directly outside
> > the loop (also to avoid introducing overlapping live ranges)
> >
> > 4) iv update statement sometimes block the forward
> > propagation/combination of the memory ref operation (depending the
> > before IV value)  with the loop branch compare. Simple minded
> > propagation will lead to overlapping live range and addition copy/move
> > instruction to be generated.
> >
> > 5) In estimating the global cost (register pressure), the registers
> > resulting from LIM of invariant expressions are not considered
> >
> > 6) IN MEM_REF creation, loop variant and invariants may be assigned to
> > the same part -- which is essentially a re-association blocking LIM
> >
> > 7) Intrinsic calls that are essentially memory operations are not
> > recognized as uses.
> 
> 8) Replacement pointer induction variables do not inherit alias-information
> pessimizing MEM_REF memory operations.

9) IVopts seems to be compile time hog, especially compiling gamess from SPEC2k6.

Honza



More information about the Gcc-patches mailing list