On Tue, Sep 29, 2009 at 8:23 PM, David Edelsohn dje@gmail.com wrote:
On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Can't we use graphite to re-roll loops? That is, compress the
polyhedron by introducing a new parameter? But maybe I am
not good at
On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Can't we use graphite to re-roll loops? That is, compress the
polyhedron by introducing a new parameter? But maybe I am
not good at guessing what your initial bloat issue looks like.
The reason I'm asking
On Thu, Aug 20, 2009 at 3:19 AM, Albert Cohenalbert.co...@inria.fr wrote:
Richard Guenther wrote:
gfortran.dg/reassoc_4.f, the hottest loop from calculix.
Thanks.
This example is slightly different. Graphite should be able to handle it
with loop fusion rather than pre-unrolling + cse. But
IIRC another code that is improved by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
Can't we use graphite to re-roll loops? ...
Is doing and undoing always some kind of work?
Cheers
Dominique
On Thu, Aug 20, 2009 at 11:48 AM, Dominique Dhumieresdomi...@lps.ens.fr wrote:
IIRC another code that is improved by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
Can't we use graphite to re-roll loops? ...
Richard Guenther wrote:
If this is not clear, I can write some pseudo-code to clarify :-).
Can't we use graphite to re-roll loops? That is, compress the
polyhedron by introducing a new parameter? But maybe I am
not good at guessing what your initial bloat issue looks like.
The reason
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one does not do any harm.
Strangely, this early unrolling pass (tuned to only
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one does not do any harm.
On Wed, Aug 19, 2009 at 2:07 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the
Richard Guenther wrote:
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more, and
maybe come up with yet another pass ordering proposal, but definitely
this tramp3d code deserves to be processed by graphite AFTER
unrolling+cse has done
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohenalbert.co...@inria.fr wrote:
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more, and
maybe come up with yet another pass ordering proposal, but definitely
this
On Wed, Aug 19, 2009 at 3:56 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohenalbert.co...@inria.fr wrote:
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more,
Richard Guenther wrote:
gfortran.dg/reassoc_4.f, the hottest loop from calculix.
Thanks.
This example is slightly different. Graphite should be able to handle it
with loop fusion rather than pre-unrolling + cse. But I agree that the
unrolling + cse approach also makes sense (and does not
14 matches
Mail list logo
