This is the mail archive of the gcc-bugs@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]

[Bug target/29256] [4.9/5/6 regression] loop performance regression


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256

--- Comment #56 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #53)
> I'm not a fan of a tree-level unroller.  It's impossible to make good
> decisions about unroll factors that early.  But your second approach sounds
> quite promising to me.

I would be willing to soften this statement.  I think that an early unroller
might well be a profitable approach for most systems with large caches and so
forth, where if the unrolling heuristics are not completely accurate we are
still likely to make a reasonably good decision.  However, I would expect to
see ports with limited caches/memory to want more accurate control over
unrolling decisions.  So I could see allowing ports to select between a GIMPLE
unroller and an RTL unroller (I doubt anybody would want both).

In general it seems like PowerPC could benefit from more aggressive unrolling
much of the time, provided we can also solve the related IVOPTS problems that
cause too much register spill.

I may have an interest in working on a GIMPLE unroller, depending on how
quickly I can complete or shed some other projects...


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