I've been thinking further about instruction alternative selection prior
to allocation and one of the questions in my mind is how this interacts
with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of an alternative will often restrict the
reg
Jeff Law wrote:
> We'd want to encode [early insn alternative selection]
> information in the conflict graph so that IRA would
> allocate registers so as to fit the constraints of the early insn
> alternative selection. Right? In the case where the graph is
> uncolorable, do we allow IRA to over
Hi,
On Fri, 13 Feb 2009, Paolo Bonzini wrote:
> > We'd want to encode [early insn alternative selection] information in
> > the conflict graph so that IRA would allocate registers so as to fit
> > the constraints of the early insn alternative selection. Right? In
> > the case where the graph
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of an alternative will often
> As for copies, I think it would be a bad decision to stick only to
> original (after the code selection) alternative and generate copies to
> satisfy this alternative. For example, if pseudo got memory instead of
> hard-register required by the alternative, it would be bad to generate a
> copy
Paolo Bonzini wrote:
Jeff Law wrote:
We'd want to encode [early insn alternative selection]
information in the conflict graph so that IRA would
allocate registers so as to fit the constraints of the early insn
alternative selection. Right? In the case where the graph is
uncolorable, do we
Paolo Bonzini writes:
>> That is in brief how I see it and there are a lot of reload details
>> missed (like virtual register eliminations or addressing displacement
>> constraints etc).
>
> I suppose those would stay in reload?
I see no reason for those to stay in reload (especially since I thi
Ian Lance Taylor wrote:
Paolo Bonzini writes:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
I see no reason for those to stay in
Paolo Bonzini wrote:
As for copies, I think it would be a bad decision to stick only to
original (after the code selection) alternative and generate copies to
satisfy this alternative. For example, if pseudo got memory instead of
hard-register required by the alternative, it would be bad to gen
On Fri, Feb 13, 2009 at 8:53 PM, Jeff Law wrote:
>>> That is in brief how I see it and there are a lot of reload details
>>> missed (like virtual register eliminations or addressing displacement
>>> constraints etc).
>>>
>>
>> I suppose those would stay in reload?
>
> Ideally they'd all move into
Steven Bosscher wrote:
On Fri, Feb 13, 2009 at 8:53 PM, Jeff Law wrote:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
Ideally
Ian Lance Taylor wrote:
Paolo Bonzini writes:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
I see no reason for those to stay in
Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of a
Michael Matz wrote:
Hi,
On Fri, 13 Feb 2009, Paolo Bonzini wrote:
We'd want to encode [early insn alternative selection] information in
the conflict graph so that IRA would allocate registers so as to fit
the constraints of the early insn alternative selection. Right? In
the case where
Hi,
On Mon, 16 Feb 2009, Jeff Law wrote:
> > If the initial alternative selection was done cleverly (like chose the
> > alternatives allowing the largest register sets which don't
> > immediately create conflicting demands for a pseudo register) the
> > opportunities for making an uncolorable
Jeff Law writes:
> Ian Lance Taylor wrote:
>>
>> I see no reason for those to stay in reload (especially since I think
>> reload should disappear entirely). It is reasonable to pick the total
>> maximum size of the stack frame, and thus resolve all displacement
>> constraints, before register al
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displacement
constraints,
Jeff Law writes:
>>> I would agree that careful relaxation of displacements is no longer as
>>> important as it once was, I don't think we can just hand wave away
>>> the displacement issues
>>>
>>> 1. The stack frames don't have to be that big to bump up against
>>> these problems.
>>>
>>> 2.
Jeff Law wrote:
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displaceme
Jeff Law wrote:
Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- t
Ian Lance Taylor wrote:
> No, that makes no sense. What I'm suggesting is that we fix the stack
> offsets of all local variables before register allocation, based on a
> conservative assessment of how many registers will be saved on the
> stack.
The conservative assessment is that all pseudos go
Ian Lance Taylor wrote:
Jeff Law writes:
I would agree that careful relaxation of displacements is no longer as
important as it once was, I don't think we can just hand wave away
the displacement issues
1. The stack frames don't have to be that big to bump up against
these problems.
2.
Vladimir Makarov wrote:
IMHO, another important optimization what reload does for such
processors is usage of already calculated displacement whose value is
in hard register to calculate an new displacement (that was
implemented by Joern for SH).
ISTM this optimization could be done with a pr
On Tue, Feb 17, 2009 at 5:51 PM, Bernd Schmidt wrote:
> The conservative assessment is that all pseudos go on the stack.
> However, this way you'll generate terrible code.
Yes. So make a not-too-optimistic estimate. And if it turns out your
estimate is too small, then you roll back, update the es
Jeff Law writes:
>> No, that makes no sense. What I'm suggesting is that we fix the stack
>> offsets of all local variables before register allocation, based on a
>> conservative assessment of how many registers will be saved on the
>> stack. Then we know during register allocation whether the
Bernd Schmidt writes:
> Ian Lance Taylor wrote:
>
>> No, that makes no sense. What I'm suggesting is that we fix the stack
>> offsets of all local variables before register allocation, based on a
>> conservative assessment of how many registers will be saved on the
>> stack.
>
> The conservative
2009/2/17 Ian Lance Taylor :
>
> The problem with reload is that it interferes with register allocation.
> Even if gcc had a perfect register allocator, we would still generate
> suboptimal code because reload would mess up the allocation. The key to
> solving that problem is that we need to do in
Ian Lance Taylor wrote:
Jeff Law writes:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
stack. Then we know during register alloc
Ian Lance Taylor wrote:
Bernd Schmidt writes:
Ian Lance Taylor wrote:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
stack.
Jeff Law writes:
> Ian Lance Taylor wrote:
>> Jeff Law writes:
>>
>>
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
>
Ian Lance Taylor wrote:
Not a conservative guess at pseudo registers, a conservative guess at
hard registers.
I'm sorry, but I think I'm done with this thread. I'm just repeating
myself, and people are critiquing things which I am not saying.
FWIW, I'm not trying to be dense -- I respect and
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
Jeff Law writes:
No, that makes no sense. What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers wil
32 matches
Mail list logo
