Richard Earnshaw wrote:
> So under what circumstances does it lead to sub-optimal code?
If the cost is incorrect Combine can make the wrong decision, for example
whether to emit a multiply-add or not. I'm not sure whether this still happens
as Kyrill fixed several issues in Combine since this patc
On 20/07/16 16:28, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Both of which look reasonable to me.
>
> Yes the code we generate for these examples is fine, I don't believe this
> example ever went bad. It's just the cost calculation that is incorrect with
> the outer check.
>
> Wilco
>
>
Richard Earnshaw wrote:
> Both of which look reasonable to me.
Yes the code we generate for these examples is fine, I don't believe this
example ever went bad. It's just the cost calculation that is incorrect with
the outer check.
Wilco
On 20/07/16 14:40, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Why does combine care what the cost is if the instruction isn't valid?
>
> No idea. Combine does lots of odd things that don't make sense to me.
> Unfortunately the costs we give for cases like this need to be accurate or
> the
Richard Earnshaw wrote:
> Why does combine care what the cost is if the instruction isn't valid?
No idea. Combine does lots of odd things that don't make sense to me.
Unfortunately the costs we give for cases like this need to be accurate or
they negatively affect code quality. The reason for thi
On 20/07/16 14:08, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> I'm not sure about this, while rtx_cost is called recursively as it
>> walks the RTL, I'd normally expect the outer levels of the recursion to
>> catch the cases where zero-extend is folded into a more complex
>> operation. Hitt
Richard Earnshaw wrote:
> I'm not sure about this, while rtx_cost is called recursively as it
> walks the RTL, I'd normally expect the outer levels of the recursion to
> catch the cases where zero-extend is folded into a more complex
> operation. Hitting a case like this suggests that something is
On 19/07/16 16:31, Wilco Dijkstra wrote:
> When zero extending a 32-bit value to 64 bits, there should always be a
> SET operation on the outside, according to the patterns in aarch64.md.
> However, the mid-end can also ask for the cost of a made-up instruction,
> where the zero-extend is part of a
When zero extending a 32-bit value to 64 bits, there should always be a
SET operation on the outside, according to the patterns in aarch64.md.
However, the mid-end can also ask for the cost of a made-up instruction,
where the zero-extend is part of another operation, not SET.
In this case we curre
