On Tue, Jul 11, 2017 at 11:14:20AM +0200, Georg-Johann Lay wrote:
> On 10.07.2017 23:40, Segher Boessenkool wrote:
> >On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
> >>Any ideas for a sane approach?
> >
> >You could change insn_rtx_cost to actually calculate the cost of the
> >i
On 07/10/2017 05:10 PM, Georg-Johann Lay wrote:
> (set (zero_extract:QI (reg/i:QI 24 r24)
> (const_int 1 [0x1])
> (const_int 6 [0x6]))
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6])))
> The problem is that the backend only sees
>
> avr_rtx_costs[bset:combine(266)]=tr
On 10.07.2017 23:40, Segher Boessenkool wrote:
On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
Any ideas for a sane approach?
You could change insn_rtx_cost to actually calculate the cost of the
insn, not just set_src_cost of a single set. This will need checking
on a great
On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
> Any ideas for a sane approach?
You could change insn_rtx_cost to actually calculate the cost of the
insn, not just set_src_cost of a single set. This will need checking
on a great many targets, not in the least because most targe
roy rosen schrieb:
> Thanks Georg,
> The -fdump-rtl-combine-details really helps.
> Regarding implementing it through cbranchhi4, this is not enough for
> me because when getting to this pattern the operands have already been
> expanded, and I am trying to prevent that.
> Is there a way around it?
roy rosen writes:
> In my port I get to such a situation:
>
> (insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
> (zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
> (const_int 16 [0x10])
> (const_int 16 [0x10]))) 53 {extzv} (nil))
>
>
