On Fri, Jun 23, 2006 at 03:23:04PM -0400, Andrew MacLeod wrote:
> A new register allocator written from scratch is a very long term
> project (measured in years), and there is no guarantee after all that
> work that we'd end up with something which is remarkably better. One
> would hope that it is
Andrew MacLeod wrote:
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
Andrew MacLeod wrote:
The SSA pressure relief through rematerialization described in
Simpson's theses is oriented for such architectures (with a big
regular register file size of 32 as I remember). So
On 6/26/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
> Andrew MacLeod wrote:
> Having no information about the final register allocator decision,
> the partial register pressure reducing through rematerialization is
> not working i
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
> Andrew MacLeod wrote:
> Having no information about the final register allocator decision,
> the partial register pressure reducing through rematerialization is
> not working in many cases. For example, making rematerialization of
Andrew MacLeod wrote:
o register pressure relief through live range splitting and/or
rematerialization. We have no accurate information here, because
after that there are passes which change the pressure like insn
Sure, Im not suggesting that RABLET will reduce the register pressure
On Sat, 2006-06-24 at 12:36 -0400, Vladimir N. Makarov wrote:
> Steven Bosscher wrote:
> As for Andrew's proposal, my opinion is that all this
> transformations are done too early and we need them to do again on
> rtl sometime.
>
> o coalescing. CSE can create more moves but more important thi
On Sat, 2006-06-24 at 13:04 +0200, Steven Bosscher wrote:
> On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> >=
> > In general, I didnt mention anything that tends not to increase register
> > pressure, at least not in any signif
Steven Bosscher wrote:
Every time some RTL optimizer is re-re-re-re-re-evaluated, it turns
out we lose without it. Good luck to you, but I think you're seriously
underestimating the complexity of things here.
Its clearly not as good as a new register allocator would be, but the
effort to be
On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> You omitted the RTL loop optimizer passes, which still do quite a bit
> of work despite the tree-ssa loop passes. Also if-conversion and some
> minor passes, though they are less r
Andrew MacLeod <[EMAIL PROTECTED]> writes:
> On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
>
> > You omitted the RTL loop optimizer passes, which still do quite a bit
> > of work despite the tree-ssa loop passes. Also if-conversion and some
> > minor passes, though they are less rel
On Jun 23, 2006, at 9:39 PM, Andrew MacLeod wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
You omitted the RTL loop optimizer passes, which still do quite a bit
of work despite the tree-ssa loop passes. Also if-conversion and
some
minor passes, though they are less rele
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> You omitted the RTL loop optimizer passes, which still do quite a bit
> of work despite the tree-ssa loop passes. Also if-conversion and some
> minor passes, though they are less relevant.
Which brings up a good discussion. I presume t
On Fri, 2006-06-23 at 23:08 -0400, Daniel Berlin wrote:
> Ian Lance Taylor wrote:
> >
> > Here I think you are waving your hands a little too hard. RTL level
> > CSE is significant for handling common expressions exposed by address
> > calculations and by DImode (and larger) computations. On so
Ian Lance Taylor wrote:
> Andrew MacLeod <[EMAIL PROTECTED]> writes:
>
>> This describes my current work-in-progress, RABLET, which stands for
>> RABLE-Themes, and conveniently implies something smaller.
>
> Thanks for this proposal.
>
>
>> ssa-to-rtl
>> spill cost analysis
>> global allocation
On 6/23/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
...
1 - One of the core themes in RABLE was very early selection of
instructions from patterns. RTL patterns are initially chosen by the
EXPAND pass. EXPAND tends to generates better rtl patterns by being
handed complex trees which it can pro
Andrew MacLeod <[EMAIL PROTECTED]> writes:
> This describes my current work-in-progress, RABLET, which stands for
> RABLE-Themes, and conveniently implies something smaller.
Thanks for this proposal.
> ssa-to-rtl
> spill cost analysis
> global allocation
> spiller
> spill location optimizer
> i
Steven Bosscher wrote:
Now, what do you think about this RABLET idea, which has nothing to do
with either register allocation or scheduling? ;-)
Well I would not say that it has nothing to do with register allocation!
But indeed this seems a promising approach. The real question in my mind
is
On 6/23/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Well I am not sure what he meant, but for sure it is not the
case that optimal register allocation and scheduling is of only
theoretical or academic interest with no practical consequences!
Thanks for making that point.
Now, what do you think
Daniel Jacobowitz wrote:
Please try the other definition, which he clearly meant:
2. Of purely theoretical or academic interest; having no
practical consequence; as, the team won in spite of the
bad call, and whether the ruling was correct is a moot
question.
Well
On Fri, Jun 23, 2006 at 04:30:01PM -0400, Robert Dewar wrote:
> >However, RABLET is not writing a register allocator so its moot
> >anyway :-).
>
> indeed, moot = disussable, undecided, so here we are discussing
> (or if you like to use the verb, mooting) the issue.
Please try the other definitio
Andrew MacLeod wrote:
I am personally not a believer in combining register allocation and
scheduling. They are two different problems, and although there is some
interaction, I am still in the "keep them seperate" camp.
I disagree, there is in fact much more than "some interaction", there
is
On Fri, 2006-06-23 at 15:29 -0400, Robert Dewar wrote:
> Andrew MacLeod wrote:
>
> > A new register allocator written from scratch is a very long term
> > project (measured in years), and there is no guarantee after all that
> > work that we'd end up with something which is remarkably better. One
Andrew MacLeod wrote:
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up with something which is remarkably better. One
would hope that it is a lot more maintainable, but the generated code
Last fall I produced the RABLE document which described the approach I
thought should be taken to write a new register allocator for GCC.
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up w
24 matches
Mail list logo
