Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-13 Thread Segher Boessenkool
On Fri, Nov 13, 2015 at 11:17:38AM +0100, Uros Bizjak wrote: > IMO, this is such a small code-size regression, that it should not > block the patch submission. In that case: Kyrill, the patch is okay for trunk. Thanks! > It would be nice to know, what causes the > increase (in case, this is

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-13 Thread Kyrill Tkachov
Hi all, On 10/11/15 19:53, Segher Boessenkool wrote: On Mon, Nov 09, 2015 at 03:51:32AM -0600, Segher Boessenkool wrote: >From the original patch submission, it looks that this patch would also benefit x86_32. Yes, that is what I thought too. Regarding the above code size increase - do you

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-13 Thread Uros Bizjak
On Fri, Nov 13, 2015 at 11:10 AM, Kyrill Tkachov wrote: > Hi all, > > On 10/11/15 19:53, Segher Boessenkool wrote: >> >> On Mon, Nov 09, 2015 at 03:51:32AM -0600, Segher Boessenkool wrote: >From the original patch submission, it looks that this patch would

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-10 Thread Segher Boessenkool
On Mon, Nov 09, 2015 at 03:51:32AM -0600, Segher Boessenkool wrote: > > >From the original patch submission, it looks that this patch would > > also benefit x86_32. > > Yes, that is what I thought too. > > > Regarding the above code size increase - do you perhaps have a > > testcase, to see

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-09 Thread Segher Boessenkool
On Mon, Nov 09, 2015 at 08:52:13AM +0100, Uros Bizjak wrote: > On Sun, Nov 8, 2015 at 9:58 PM, Segher Boessenkool > wrote: > > On Fri, Nov 06, 2015 at 04:00:08PM -0600, Segher Boessenkool wrote: > >> This patch stops combine from generating widening muls of anything

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-08 Thread Segher Boessenkool
On Fri, Nov 06, 2015 at 04:00:08PM -0600, Segher Boessenkool wrote: > This patch stops combine from generating widening muls of anything else > but registers (immediates, memory, ...). This probably is a reasonable > tradeoff for all targets, even those (if any) that have such insns. > > > >I'll

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-08 Thread Uros Bizjak
On Sun, Nov 8, 2015 at 9:58 PM, Segher Boessenkool wrote: > On Fri, Nov 06, 2015 at 04:00:08PM -0600, Segher Boessenkool wrote: >> This patch stops combine from generating widening muls of anything else >> but registers (immediates, memory, ...). This probably is a

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-06 Thread Kyrill Tkachov
On 06/11/15 00:56, Segher Boessenkool wrote: On Thu, Nov 05, 2015 at 12:01:26PM +, Kyrill Tkachov wrote: Thanks, that looks less intrusive. I did try it out on arm and aarch64. It does work on the aarch64 testcase. However, there's also a correctness regression, I'll try to explain

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-06 Thread Jeff Law
On 11/06/2015 07:19 AM, Kyrill Tkachov wrote: I think we should also add: && REG_P (XEXP (XEXP (x, 0), 0)) && REG_P (XEXP (XEXP (x, 1), 0)) I tend to agree. Yep, see new patch. The "from == to" condition is for when subst is called just to simplify some code (normally with

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-06 Thread Segher Boessenkool
[ reordered a bit ] On Fri, Nov 06, 2015 at 02:14:12PM -0700, Jeff Law wrote: > On 11/06/2015 07:19 AM, Kyrill Tkachov wrote: > >>>I think we should also add: > >>> && REG_P (XEXP (XEXP (x, 0), 0)) > >>> && REG_P (XEXP (XEXP (x, 1), 0)) > I tend to agree. > >Indeed, this looks better

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-05 Thread Kyrill Tkachov
Hi Segher, On 04/11/15 23:50, Segher Boessenkool wrote: Hi Kyrill, On Mon, Nov 02, 2015 at 02:15:27PM +, Kyrill Tkachov wrote: This patch attempts to restrict combine from transforming ZERO_EXTEND and SIGN_EXTEND operations into and-bitmask and weird SUBREG expressions when they appear

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-05 Thread Segher Boessenkool
On Thu, Nov 05, 2015 at 12:01:26PM +, Kyrill Tkachov wrote: > Thanks, that looks less intrusive. I did try it out on arm and aarch64. > It does work on the aarch64 testcase. However, there's also a correctness > regression, I'll try to explain inline > >diff --git a/gcc/combine.c

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-04 Thread Segher Boessenkool
Hi Kyrill, On Mon, Nov 02, 2015 at 02:15:27PM +, Kyrill Tkachov wrote: > This patch attempts to restrict combine from transforming ZERO_EXTEND and > SIGN_EXTEND operations into and-bitmask > and weird SUBREG expressions when they appear inside MULT expressions. This > is because a MULT rtx

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-04 Thread Kyrill Tkachov
On 04/11/15 11:37, Kyrill Tkachov wrote: On 02/11/15 22:31, Jeff Law wrote: On 11/02/2015 07:15 AM, Kyrill Tkachov wrote: Hi all, This patch attempts to restrict combine from transforming ZERO_EXTEND and SIGN_EXTEND operations into and-bitmask and weird SUBREG expressions when they appear

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-04 Thread Kyrill Tkachov
Ji Jrgg, On 02/11/15 22:31, Jeff Law wrote: On 11/02/2015 07:15 AM, Kyrill Tkachov wrote: Hi all, This patch attempts to restrict combine from transforming ZERO_EXTEND and SIGN_EXTEND operations into and-bitmask and weird SUBREG expressions when they appear inside MULT expressions. This is

Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults

2015-11-02 Thread Jeff Law
On 11/02/2015 07:15 AM, Kyrill Tkachov wrote: Hi all, This patch attempts to restrict combine from transforming ZERO_EXTEND and SIGN_EXTEND operations into and-bitmask and weird SUBREG expressions when they appear inside MULT expressions. This is because a MULT rtx containing these extend