On 11/02/11 19:41, Ian Lance Taylor wrote:
My case was somewhat different. I think I just patched gcse_constant_p.
Thanks!
"Paulo J. Matos" writes:
> On 10/02/11 16:04, Ian Lance Taylor wrote:
>> Bother. I've encountered that problem before and I think I used a
>> sledgehammer (a local patch). It's definitely a bug that gcse doesn't
>> consider costs.
>>
>
> I think I might try also patching my local gcc. I guess t
On 10/02/11 16:04, Ian Lance Taylor wrote:
Bother. I've encountered that problem before and I think I used a
sledgehammer (a local patch). It's definitely a bug that gcse doesn't
consider costs.
I think I might try also patching my local gcc. I guess the trick is to
check for the cost of th
On 10/02/11 17:59, Richard Henderson wrote:
If constants are never valid as the source of a store,
They are but it really depends to which registers they are going to. If
the destination belongs to a certain class it is ok, for all the others
it is not. It is tricky even to define costs when
On 02/09/2011 07:07 AM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> But then this is combined by cse into:
>>
>> (set (mem/s:QI (reg:QI 41)) (const_int 0))
>>
>> and bammm, same problem. No loop hoisting. What's the best way to
>> handle this? Any suggestions?
>
> You need to set TAR
"Paulo J. Matos" writes:
> On 10/02/11 16:04, Ian Lance Taylor wrote:
>>
>> Bother. I've encountered that problem before and I think I used a
>> sledgehammer (a local patch). It's definitely a bug that gcse doesn't
>> consider costs.
>>
>
> At least I am happy that you confirm this. :) Have you
On 10/02/11 16:04, Ian Lance Taylor wrote:
Bother. I've encountered that problem before and I think I used a
sledgehammer (a local patch). It's definitely a bug that gcse doesn't
consider costs.
At least I am happy that you confirm this. :) Have you reported a bug
for this before?
"Paulo J. Matos" writes:
> On 09/02/11 15:57, Ian Lance Taylor wrote:
>
>> For your processor it sounds like you should make a constant more
>> expensive than a register for an outer code of SET. You're right that
>> the cost should really depend on the destination of the set but
>> unfortunatel
On 09/02/11 15:57, Ian Lance Taylor wrote:
For your processor it sounds like you should make a constant more
expensive than a register for an outer code of SET. You're right that
the cost should really depend on the destination of the set but
unfortunately I don't know if you will see that.
I
On 09/02/11 15:57, Ian Lance Taylor wrote:
For your processor it sounds like you should make a constant more
expensive than a register for an outer code of SET. You're right that
the cost should really depend on the destination of the set but
unfortunately I don't know if you will see that.
I a
"Paulo J. Matos" writes:
> It is slightly confusing for me the way it works. I have added a debug
> printf in it so I can debug the costs and when they are called and I
> get a list like this:
>
> == RTXCOST[pass]: outer_code rtx => cost rec/done==
>
> And it starts with:
> == RTXCOST[]: UnKnown
On 09/02/11 15:07, Ian Lance Taylor wrote:
You need to set TARGET_RTX_COSTS to indicate that this operation is
relatively expensive. That should stop combine from generating it.
Thanks, I will give it a try. One of the things that are not as polished
as it should is exactly the rtx costs. I
"Paulo J. Matos" writes:
> But then this is combined by cse into:
>
> (set (mem/s:QI (reg:QI 41)) (const_int 0))
>
> and bammm, same problem. No loop hoisting. What's the best way to
> handle this? Any suggestions?
You need to set TARGET_RTX_COSTS to indicate that this operation is
relatively ex
13 matches
Mail list logo
