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
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
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
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
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
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
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
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
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
[ 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
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
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
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
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
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
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
16 matches
Mail list logo