Jeff Law wrote:
Vladimir Makarov wrote:
Dave Korn wrote:
In a brief exchange I had with Michael off-list, we discussed
that. I
observed that of the things that reload does,
constraint-satisfaction/insn-variant-selection is its primary
purpose, and
spill/reload code generation is something
Vladimir Makarov wrote:
Dave Korn wrote:
Albert Cohen wrote:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks c
Vladimir Makarov wrote:
So, now my questions: How much do you think could this could improve
compiled code speed? Would the current GCC/YARA benefit from such an
optimization pass at all?
I think nobody can answer the questions until it is implemented.
Agreed.
If you are going to work on t
Dave Korn wrote:
Albert Cohen wrote:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks currently managed by relo
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
Vladimir Makarov schrieb:
Michael Kruse wrote:
In the thesis, a modified Poletto algorithm is presented to add spill
code.
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 Chait
Michael Kruse wrote:
Vladimir Makarov wrote:
Michael Kruse wrote:
If the register sufficiency is higher than the physical number of
registers, spill code is added to the graph.
For me, that is the most interesting part, unfortunately Touti (as I
remember) in his thesis say practically noth
Vladimir Makarov wrote:
Michael Kruse wrote:
If the register sufficiency is higher than the physical number of
registers, spill code is added to the graph.
For me, that is the most interesting part, unfortunately Touti (as I
remember) in his thesis say practically nothing about this.
In th
Dave Korn wrote:
Albert Cohen wrote:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks currently managed by relo
Dave Korn wrote:
Michael Kruse wrote:
So, now my questions: How much do you think could this could improve
compiled code speed? Would the current GCC/YARA benefit from such an
optimization pass at all? What are the chances that this could get into
the main GCC tree if it shows up to be an im
Michael Kruse wrote:
Hello GCC developers,
I am going to write a Master's Thesis about instruction scheduling
based on the technique presented in [1]. This will also include a
implementation.
The basic idea is to have an additional pass on the data dependency
graph before instruction schedu
David Edelsohn wrote:
> -- Forwarded message --
> From: Albert Cohen
> Date: Sun, Jun 28, 2009 at 6:25 PM
> Subject: Re: Register Pressure in Instruction Level Parallelism
> To: Dave Korn
> Cc: re...@meinersbur.de, gcc@gcc.gnu.org, Sid Touati
> , Frederic
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
Hi,
Albert Cohen schrieb:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Do have any specific publication in mind? At the moment, my
Michael Kruse wrote:
> [Posting this again because I noticed that I sent this to Dave Korn only]
Wasn't sure if you just meant to keep our idle chatter off the public list
or not. I think I summed up the salient points of our discussion in my other
post just now, no?
cheers,
DaveK
Albert Cohen wrote:
> Unfortunately, the state of the art (more recent that the thesis
> referenced in the original email, see Touati's web page) is limited to
> basic block and software-pipelining scopes, and limited to scheduling.
>
> Compared to the tasks currently managed by reload, it certai
[Posting this again because I noticed that I sent this to Dave Korn only]
Hi Dave,
Dave Korn wrote:
> One of the major problems in gcc is the intertangling of instruction
> selection with register allocation and spill generation. If these
could be
> separated it would almost certainly genera
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
Michael Kruse wrote:
> So, now my questions: How much do you think could this could improve
> compiled code speed? Would the current GCC/YARA benefit from such an
> optimization pass at all? What are the chances that this could get into
> the main GCC tree if it shows up to be an improvement?
O
Hello GCC developers,
I am going to write a Master's Thesis about instruction scheduling based
on the technique presented in [1]. This will also include a implementation.
The basic idea is to have an additional pass on the data dependency
graph before instruction scheduling and register alloc
20 matches
Mail list logo
