Re: [PATCH] i386: Improve ix86_expand_int_movcc

2022-04-26 Thread Uros Bizjak via Gcc-patches
On Tue, Apr 26, 2022 at 8:44 AM Jakub Jelinek wrote: > > Hi! > > When working on PR105338, I've noticed that in some cases we emit > unnecessarily long sequence which has then higher seq_cost than necessary. > > E.g. when ix86_expand_int_movcc is called with > operands[0] (reg/v:SI 83 [ i ]) > ope

[PATCH] i386: Improve ix86_expand_int_movcc

2022-04-25 Thread Jakub Jelinek via Gcc-patches
Hi! When working on PR105338, I've noticed that in some cases we emit unnecessarily long sequence which has then higher seq_cost than necessary. E.g. when ix86_expand_int_movcc is called with operands[0] (reg/v:SI 83 [ i ]) operands[1] (eq (reg/v:SI 83 [ i ]) (const_int 0 [0])) operands[2] (reg/v

Re: [PATCH] i386: Improve ix86_expand_int_movcc [PR105338]

2022-04-23 Thread Uros Bizjak via Gcc-patches
On Sat, Apr 23, 2022 at 8:53 AM Jakub Jelinek wrote: > > Hi! > > The following testcase regressed on x86_64 on the trunk, due to some GIMPLE > pass changes (r12-7687) we end up an *.optimized dump difference of: > @@ -8,14 +8,14 @@ int foo (int i) > > [local count: 1073741824]: >if (i_2(D)

[PATCH] i386: Improve ix86_expand_int_movcc [PR105338]

2022-04-22 Thread Jakub Jelinek via Gcc-patches
Hi! The following testcase regressed on x86_64 on the trunk, due to some GIMPLE pass changes (r12-7687) we end up an *.optimized dump difference of: @@ -8,14 +8,14 @@ int foo (int i) [local count: 1073741824]: if (i_2(D) != 0) -goto ; [35.00%] +goto ; [35.00%] else -goto ;