make insn_rtx_cost take account
>>>>> of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly
>>>>> beginning to realise that I don't understand what rtx costs are
>>>>> supposed to represent.
>>>>>
>>>>&g
>>>> of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
>>>> to realise that I don't understand what rtx costs are supposed to
>>>> represent.
>>>>
>>>> AIUI the rules have historically been:
>>>>
>
On Mon, Aug 22, 2011 at 9:08 AM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>>> So are you saying that we should remove the recursive nature of the
>>> rtx_cost/targetm.rtx_costs interface, and have the backend handle any
>>> recursion itself? I.e. targetm.rtx_costs only ever sees a com
Quoting Richard Guenther :
So are you saying that we should remove the recursive nature of the
rtx_cost/targetm.rtx_costs interface, and have the backend handle any
recursion itself? I.e. targetm.rtx_costs only ever sees a complete
(but perhaps invalid) instruction pattern? Or would you still
>>> expensive.
>> No, that complexity is not needed. For (set (reg) (const_int)) the BE
>> can just return the cost of the expanded sequence because it knows how
>> it will be expanded and how much it will cost. There's no need to
>> really expand the sequence
instruction. But that's potentially
>>> expensive.
>>
>> No, that complexity is not needed. For (set (reg) (const_int)) the BE
>> can just return the cost of the expanded sequence because it knows how
>> it will be expanded and how much it will cost. There&
r (set (reg) (const_int)) the BE
> can just return the cost of the expanded sequence because it knows how
> it will be expanded and how much it will cost. There's no need to
> really expand the sequence.
Sorry, I'd misunderstood your suggestion. I thought you were suggesting
Richard Sandiford schrieb:
Georg-Johann Lay writes:
Richard Sandiford schrieb:
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
to realise that I don't understand what rtx costs
Hans-Peter Nilsson writes:
>> But that hardly seems clean either. Perhaps we should instead make
>> the SET_SRC always include the cost of the SET, even for registers,
>> constants and the like. Thoughts?
>
> Seems more of maintaining a wart than an improvement for
> consistency.
So, to enumera
Georg-Johann Lay writes:
> Richard Sandiford schrieb:
>> I've been working on some patches to make insn_rtx_cost take account
>> of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
>> to realise that I don't understand what rtx costs are su
improve
> this area for consistency: between releases a port already
> usually arbitrarily loses on some type of codes and costs have
> to be re-tweaked, unless performance is closely tracked.
Yeah, probably true. Certainly a good excuse for me to use. :-)
> Aiming for traceability can
Thanks for the feedback.
Paolo Bonzini writes:
> On 08/17/2011 07:52 AM, Richard Sandiford wrote:
>>cost = rtx_cost (SET_SRC (set), SET, speed);
>>return cost> 0 ? cost : COSTS_N_INSNS (1);
>>
>> This ignores SET_DEST (the problem I'm trying to fix). It also means
>> that constants that
than an improvement for
consistency.
I don't think you can get into trouble for trying to improve
this area for consistency: between releases a port already
usually arbitrarily loses on some type of codes and costs have
to be re-tweaked, unless performance is closely tracked.
Aiming for traceabil
On 08/17/2011 07:52 AM, Richard Sandiford wrote:
cost = rtx_cost (SET_SRC (set), SET, speed);
return cost> 0 ? cost : COSTS_N_INSNS (1);
This ignores SET_DEST (the problem I'm trying to fix). It also means
that constants that are slightly more expensive than a register --
somewhere in th
Richard Sandiford schrieb:
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
to realise that I don't understand what rtx costs are supposed to represent.
AIUI the rules have historic
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
to realise that I don't understand what rtx costs are supposed to represent.
AIUI the rules have historically been:
1) Registers have
Ian Lance Taylor writes:
> pocma...@gmail.com (Paulo J. Matos) writes:
>
> For most processors it's not important to get all costs exactly correct.
> The compiler uses the costs in a relatively brute force manner. If
> there is only one way to do some operation, then its cost is irrelevant.
> Co
ks for:
> - register move
> - memory move
> - branches
> - rtx
> - address
>
> only the last two refer to the use of COSTS_N_INSNS. How do the
> value for a register move (which defaults to 2), will compare to an rtx
> cost?
You should be defining your rtx costs with the
Ian Lance Taylor writes:
> pocma...@gmail.com (Paulo J. Matos) writes:
>
>> Moreover, is there a reason for the existence of COST_N_INSNS(x) and why
>> this multiplies x by 4? Is 4 just a special number? Any reason on why I
>> should be using COST_N_INSNS instead of just assigning *total (of
>> t
pocma...@gmail.com (Paulo J. Matos) writes:
> I would like some clarification on the meaning of RTX Costs.
> When optimising for speed I assume they estimate the time at which the
> final generated code is going to take to execute for each rtx.
> When optimising for size it is t
Hello,
I would like some clarification on the meaning of RTX Costs.
When optimising for speed I assume they estimate the time at which the
final generated code is going to take to execute for each rtx.
When optimising for size it is the estimated number of words that each
rtx will generate in the
Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generat
> After reading the internal docs about rtx_costs I am left wondering what
> they exactly are estimating.
> - Are they estimating in the beginning of expand how many insns will be
> generated from a particular insn until the assembler is generated?
> - or Are they estimating how many assembler in
Quoting "Paulo J. Matos" :
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estim
Hi all,
After reading the internal docs about rtx_costs I am left wondering what
they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estimating how many assembler in
25 matches
Mail list logo
