Le 10/02/2014 10:12, Richard Biener a écrit :
Btw, Mircea - do you have a copyright assignment on file with the FSF
covering work on GCC?
Yes, Mircea is covered by an INRIA-wide copyright assignment, signed on
May 15, 2007 by T. Brown.
Thanks,
Albert
Le 10/02/2014 16:48, Albert Cohen a écrit :
Le 10/02/2014 10:12, Richard Biener a écrit :
Btw, Mircea - do you have a copyright assignment on file with the FSF
covering work on GCC?
Yes, Mircea is covered by an INRIA-wide copyright assignment, signed on
May 15, 2007 by T. Brown.
After
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
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
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
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
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
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
Richard Guenther wrote:
On Sat, May 9, 2009 at 10:42 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, May 9, 2009 at 10:07 PM, Albert Cohen albert.co...@inria.fr wrote:
Sebastian Pop and I have been discussing the option of designing a new pass,
based on vrp, to normalize integer
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
Sebastian Pop wrote:
On Wed, Apr 29, 2009 at 17:15, Richard Guenther
richard.guent...@gmail.com 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
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
Steven Bosscher wrote:
On Wed, Mar 18, 2009 at 8:17 PM, Albert Cohen albert.co...@inria.fr 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
Emmanuel Fleury wrote:
Andrew Pinski wrote:
On Wed, Mar 4, 2009 at 8:33 AM, Manuel López-Ibáñez
lopeziba...@gmail.com 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 ATT DSL so I
welcome!
Albert Cohen
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-block,
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, we
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
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
22 matches
Mail list logo
