On Thu, 9 Nov 2023, Jeff Law wrote:
> > Can we have the insn costing reverted to correct calculation?
> What needs to happen is that code needs to be extended, not reverted. Many
> codes have to be synthesized based on the condition and the true/false arms.
> That's not currently accounted for.
On 11/9/23 07:33, Maciej W. Rozycki wrote:
On Fri, 29 Sep 2023, Jeff Law wrote:
So this ends up looking a lot like the bits that I had to revert several weeks
ago :-)
The core issue we have is given an INSN the generic code will cost the SET_SRC
and SET_DEST and sum them. But that's far fr
On 11/9/23 07:33, Maciej W. Rozycki wrote:
On Fri, 29 Sep 2023, Jeff Law wrote:
So this ends up looking a lot like the bits that I had to revert several weeks
ago :-)
The core issue we have is given an INSN the generic code will cost the SET_SRC
and SET_DEST and sum them. But that's far fr
On Fri, 29 Sep 2023, Jeff Law wrote:
> So this ends up looking a lot like the bits that I had to revert several weeks
> ago :-)
>
> The core issue we have is given an INSN the generic code will cost the SET_SRC
> and SET_DEST and sum them. But that's far from ideal on a RISC target.
>
> For a r
> Date: Fri, 29 Sep 2023 16:37:21 -0600
> From: Jeff Law
> So this ends up looking a lot like the bits that I had to revert several
> weeks ago :-)
>
> The core issue we have is given an INSN the generic code will cost the
> SET_SRC and SET_DEST and sum them. But that's far from ideal on a RI
So this ends up looking a lot like the bits that I had to revert several
weeks ago :-)
The core issue we have is given an INSN the generic code will cost the
SET_SRC and SET_DEST and sum them. But that's far from ideal on a RISC
target.
For a register destination, the cost can be determin
