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 unr
Richard Guenther wrote:
> 2009/8/19 Albert Cohen :
>> 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 schedule
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 A
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 dep
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 re
Tobias Grosser wrote
Hi graphities,
graphite consists of four flags "-floop-block", "-floop-interchange",
"-floop-stripmine" and "-fgraphite".
If any of these flags is set, we enable the graphite pass and we search
for SCoPs.
For every SCoP we try to apply transformations specified with
"-floop
back welcome!
Albert Cohen
Emmanuel Fleury wrote:
Andrew Pinski wrote:
On Wed, Mar 4, 2009 at 8:33 AM, Manuel López-Ibáñez
wrote:
The proxy server received an invalid response from an upstream server.
I can access without problem.
I get the same error message that Tom gets. I am on AT&T DSL so I
doubt it is my side
Antoniu Pop wrote:
(...)
The multiple backends compilation is not directly related, so you
should use a separate branch. It makes sense to go in that direction.
Indeed.
There has been some work in the area, using different approaches. I've
been involved in one attempt, for the Cell, with Cupe
Steven Bosscher wrote:
On Wed, Mar 18, 2009 at 8:17 PM, Albert Cohen wrote:
Antoniu Pop wrote:
(...)
The multiple backends compilation is not directly related, so you
should use a separate branch. It makes sense to go in that direction.
Indeed.
Work has been going on for years in this
Sebastian Pop wrote:
On Wed, Apr 29, 2009 at 17:15, Richard Guenther
wrote:
I don't see how SSA form makes anything more complicated ;)
One of the difficulties was regenerating the phi nodes after code
hoisting: CLooG optimizes
for (i)
if (invariant of i)
s += A[i];
into
if (invaria
Sebastian Pop and I have been discussing the option of designing a new
pass, based on vrp, to normalize integer types towards a canonical
supertype typically a machine word, equivalent to signed long, or to
truncate to a smaller-size word when it makes sense. This would be a
very simple pass (o
Richard Guenther wrote:
On Sat, May 9, 2009 at 10:42 PM, Richard Guenther
wrote:
On Sat, May 9, 2009 at 10:07 PM, Albert Cohen wrote:
Sebastian Pop and I have been discussing the option of designing a new pass,
based on vrp, to normalize integer types towards a canonical supertype
typically
Hi all,
I'm convinced that saturation and sufficiency based approaches are the
future of register pressure management.
[Please keep my colleague Sid Touati in CC of this thread, until he
registers to the list.]
Unfortunately, the state of the art (more recent that the thesis
referenced in
Dave Korn wrote:
(...)
I fully agree with your arguments. Managing register pressure early, and
simplifying downstream passes (to avoid poluting them with pressure
concerns) is a very tempting design. Yet from dream to reality there is
a long way.
:) I'm not up on advanced compiler theo
Vladimir Makarov wrote:
I've just checked the thesis again. I don't think decreasing register
pressure through spilling will work well. First of all Polleto linear
scan RA is worse than Chaitin-Briggs approach. Even its major
improvement extending linear scan is worse than Chaitin-Briggs
ap
Jean-Marc Bourguet wrote:
-fmemory-model=single
Assume single threaded execution, which also means no signal
handlers.
-fmemory-model=fast
The user is responsible for all synchronization. Accessing
the same memory words from different threads may break
Hi all,
Yes, Sebastian is Right for now, and thanks for pointing out the references.
Yet in the longer term, we are working on CLooG extensions to facilitate
tiling with parametric sizes, multidomensional tiling, increased
scalability, no risks of integer overflows, and better quality of
generate
Tobias Grosser wrote:
> I would like to improve the way how we handle scalar variables and ivs
> during graphite transformation.
> I am not sure, if I got it right and where to put my code in the backend.
> So it would be great, if you could read over my ideas.
>
> The problem:
>
> In
Tobias Grosser wrote:
> (...)
> Why is there a need to name the new ones like the old ones? The only
> reason I can think about is debugging. And I am not sure if their exists
> a strong relation between old an new ones, that makes it reasonable to
> call them identical. During all the code motion,
20 matches
Mail list logo
