IRA memory cost calculation

IRA memory cost calculation

[Michael Eager]

I've run into a situation where assign_hard_reg()
decides that there are no registers available.  This
results in a memory reference being substituted for a
pseudo-register.  There's no check to see if the modified
instruction is valid, which it isn't.

There are a lot of live registers and it is possible
that there are no unused register.  assign_hard_reg()
is finding that the cost of using any of the registers
it checks is higher than the cost of a memory reference.

I looked at record_operand_costs() and record_reg_classes().
This is supposed to calculate the cost of using memory
or a hard reg for an insn's operands.  Since none of the
constraints permit a memory reference, I would expect that
the mem_cost calculated for each operand would be a high
value; instead it is low.   If I force the mem_cost value
to be high, then assign_hard_reg() does assign a register.

record_operand_costs() does initialize op_costs[] to
high values, both for memory and registers.  This is
reset in record_reg_classes() to the value from
ira_memory_move_cost[] in the following code:

    /* If the alternative actually allows memory, make
       things a bit cheaper since we won't need an extra
       insn to load it.  */
    pp->mem_cost
      = ((recog_data.operand_type[i] != OP_IN
          ? ira_memory_move_cost[mode][classes[i]][0] : 0)
      + (recog_data.operand_type[i] != OP_OUT
          ? ira_memory_move_cost[mode][classes[i]][1] : 0)
      - allows_mem[i]) * frequency;

The alternative doesn't allow memory, so I'm unclear why
mem_cost is being set.  allows_mem[] is zero for all
operands in the insn.


Can anyone give me some guidance here?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: IRA memory cost calculation

[Jeff Law]

On 11/30/09 14:17, Michael Eager wrote:
> I've run into a situation where assign_hard_reg()
> decides that there are no registers available.
That can certainly happen.  It's also the case that assign_hard_reg may 
decide that memory is cheaper than a register and refuse to assign a 
register for certain allocnos.

> This
> results in a memory reference being substituted for a
> pseudo-register.  There's no check to see if the modified
> instruction is valid, which it isn't.
reload performs this action, not IRA.   Reload is allowed to replace a 
pseudo with its equivalent memory location, then emit whatever reloads 
are necessary to fix up the resulting insn.  So what you need to do is 
debug the generated reloads for the insn in question.

Often this kind of failure is a predicate, constraint or secondary 
reload problem.


Jeff

Re: IRA memory cost calculation

[Michael Eager]

Jeff Law wrote:
> On 11/30/09 14:17, Michael Eager wrote:
>> I've run into a situation where assign_hard_reg()
>> decides that there are no registers available.
> That can certainly happen.  It's also the case that assign_hard_reg may 
> decide that memory is cheaper than a register and refuse to assign a 
> register for certain allocnos.
> 
>> This
>> results in a memory reference being substituted for a
>> pseudo-register.  There's no check to see if the modified
>> instruction is valid, which it isn't.
> reload performs this action, not IRA.   Reload is allowed to replace a 
> pseudo with its equivalent memory location, then emit whatever reloads 
> are necessary to fix up the resulting insn.  So what you need to do is 
> debug the generated reloads for the insn in question.
> 
> Often this kind of failure is a predicate, constraint or secondary 
> reload problem.

Thanks.  I did step through reload and it looked
like everything it was doing was OK.

I'll look at reload again and re-check constraints.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: IRA memory cost calculation

[Jeff Law]

On 11/30/09 14:48, Michael Eager wrote:
> Jeff Law wrote:
>> On 11/30/09 14:17, Michael Eager wrote:
>>> I've run into a situation where assign_hard_reg()
>>> decides that there are no registers available.
>> That can certainly happen.  It's also the case that assign_hard_reg 
>> may decide that memory is cheaper than a register and refuse to 
>> assign a register for certain allocnos.
>>
>>> This
>>> results in a memory reference being substituted for a
>>> pseudo-register.  There's no check to see if the modified
>>> instruction is valid, which it isn't.
>> reload performs this action, not IRA.   Reload is allowed to replace 
>> a pseudo with its equivalent memory location, then emit whatever 
>> reloads are necessary to fix up the resulting insn.  So what you need 
>> to do is debug the generated reloads for the insn in question.
>>
>> Often this kind of failure is a predicate, constraint or secondary 
>> reload problem.
>
> Thanks.  I did step through reload and it looked
> like everything it was doing was OK.
>
> I'll look at reload again and re-check constraints.
Also double check your predicates and look at secondary reload issues.  
It's not uncommon to need to define secondary reloads for oddball 
cases.   If you described more attributes of your target we might be 
able to point you at another target with similar attributes and describe 
how it handles these situations.

jeff

Re: IRA memory cost calculation

[Michael Eager]

Jeff Law wrote:
> On 11/30/09 14:48, Michael Eager wrote:
>> Jeff Law wrote:
>>> On 11/30/09 14:17, Michael Eager wrote:
>>>> I've run into a situation where assign_hard_reg()
>>>> decides that there are no registers available.
>>> That can certainly happen.  It's also the case that assign_hard_reg 
>>> may decide that memory is cheaper than a register and refuse to 
>>> assign a register for certain allocnos.
>>>
>>>> This
>>>> results in a memory reference being substituted for a
>>>> pseudo-register.  There's no check to see if the modified
>>>> instruction is valid, which it isn't.
>>> reload performs this action, not IRA.   Reload is allowed to replace 
>>> a pseudo with its equivalent memory location, then emit whatever 
>>> reloads are necessary to fix up the resulting insn.  So what you need 
>>> to do is debug the generated reloads for the insn in question.
>>>
>>> Often this kind of failure is a predicate, constraint or secondary 
>>> reload problem.
>>
>> Thanks.  I did step through reload and it looked
>> like everything it was doing was OK.
>>
>> I'll look at reload again and re-check constraints.
> Also double check your predicates and look at secondary reload issues.  
> It's not uncommon to need to define secondary reloads for oddball 
> cases.   If you described more attributes of your target we might be 
> able to point you at another target with similar attributes and describe 
> how it handles these situations.

Xilinx MicroBlaze.  Not too odd a processor -- RISC, 3-addr.
It was working OK with the IAR register allocator until  I
removed some of the branch instruction templates which
should no longer be necessary.  AFAIK, this should not have
changed constraints or predicates.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: IRA memory cost calculation

[Michael Eager]

Jeff Law wrote:
> On 11/30/09 14:48, Michael Eager wrote:
>> Jeff Law wrote:
>>> On 11/30/09 14:17, Michael Eager wrote:
>>>> I've run into a situation where assign_hard_reg()
>>>> decides that there are no registers available.
>>> That can certainly happen.  It's also the case that assign_hard_reg 
>>> may decide that memory is cheaper than a register and refuse to 
>>> assign a register for certain allocnos.
>>>
>>>> This
>>>> results in a memory reference being substituted for a
>>>> pseudo-register.  There's no check to see if the modified
>>>> instruction is valid, which it isn't.
>>> reload performs this action, not IRA.   Reload is allowed to replace 
>>> a pseudo with its equivalent memory location, then emit whatever 
>>> reloads are necessary to fix up the resulting insn.  So what you need 
>>> to do is debug the generated reloads for the insn in question.
>>>
>>> Often this kind of failure is a predicate, constraint or secondary 
>>> reload problem.
>>
>> Thanks.  I did step through reload and it looked
>> like everything it was doing was OK.
>>
>> I'll look at reload again and re-check constraints.
> Also double check your predicates and look at secondary reload issues.  
> It's not uncommon to need to define secondary reloads for oddball 
> cases.   If you described more attributes of your target we might be 
> able to point you at another target with similar attributes and describe 
> how it handles these situations.

After more hours trudging through reload, I found
out that the invalid instruction was caused by an
incorrect constraint.  This was in code dating from
gcc-2.96.  Apparently, nothing had ever matched this
combination before until I added cbranch support.

Thanks for the pointing me in the right direction.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077