> > It would be nice to only have to write the set+set version, and do
> > some markup to say which of the clobber variants should be generated,
> > yes.
>
> define_subst should be able to do that.
The Visium port uses that (but the other way around).
--
Eric Botcazou
On Sun, Jan 18, 2015 at 05:28:39PM -0600, Segher Boessenkool wrote:
> On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> > The current cc-first order happened more of an accidental
> > opinion than an architectural decision as I vaguely recall, when
> > asking. We also have the
On Sun, Jan 18, 2015 at 04:26:27PM -0500, Hans-Peter Nilsson wrote:
> For targets where most insns set condition-codes (and that don't
> use the deprecated CC0-machinery), those insns will always be
> expressed using a parallel with (most often) two members, one
> being the "main" part of the insn
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> The current cc-first order happened more of an accidental
> opinion than an architectural decision as I vaguely recall, when
> asking. We also have the canonical location of a *cc clobber*,
> i.e. last in a parallel. For that r
On Sat, 17 Jan 2015, Jakub Jelinek wrote:
> On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> > (Waking up an old thread with my 2 cents due to being a little
> > behind on reading...)
> >
> > On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > > On Sat, Dec 06, 2014 at 09:28:57AM +010
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> (Waking up an old thread with my 2 cents due to being a little
> behind on reading...)
>
> On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > > That's already what it
(Waking up an old thread with my 2 cents due to being a little
behind on reading...)
On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine
On 12/10/14 06:47, Segher Boessenkool wrote:
On Tue, Dec 09, 2014 at 12:15:30PM -0700, Jeff Law wrote:
@@ -3323,7 +3396,11 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn
*i1, rtx_insn *i0,
rtx old = newpat;
total_sets = 1 + extra_sets;
newpat = gen_rtx_PARALLE
On Fri, Dec 12, 2014 at 03:27:17PM +0800, Zhenqiang Chen wrote:
> > Presumably you're thinking about a PARALLEL that satisfies single_set_p?
>
> No. It has nothing to do with single_set_p. I just want to reuse the code to
> match the instruction pattern.
>
> In common, the new PARALLEL is like
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, December 10, 2014 3:16 AM
> To: Segher Boessenkool; Zhenqiang Chen
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix PR 61225
>
> On 12/09/14 12:07, Segher Boessenkool w
On Tue, Dec 09, 2014 at 12:15:30PM -0700, Jeff Law wrote:
> >>@@ -3323,7 +3396,11 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn
> >>*i1, rtx_insn *i0,
> >> rtx old = newpat;
> >> total_sets = 1 + extra_sets;
> >> newpat = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (total_sets));
On 12/09/14 12:07, Segher Boessenkool wrote:
On Tue, Dec 09, 2014 at 05:49:18PM +0800, Zhenqiang Chen wrote:
Do you need to verify SETA and SETB satisfy single_set? Or has that
already been done elsewhere?
A is NEXT_INSN (insn)
B is prev_nonnote_nondebug_insn (insn),
For I1 -> I2 -> B; I2 ->
On Tue, Dec 09, 2014 at 05:49:18PM +0800, Zhenqiang Chen wrote:
> > Do you need to verify SETA and SETB satisfy single_set? Or has that
> > already been done elsewhere?
>
> A is NEXT_INSN (insn)
> B is prev_nonnote_nondebug_insn (insn),
>
> For I1 -> I2 -> B; I2 -> A;
> LOG_LINK can make sure I1
On 12/09/14 02:49, Zhenqiang Chen wrote:
Do you need to verify SETA and SETB satisfy single_set? Or has that
already been done elsewhere?
A is NEXT_INSN (insn)
B is prev_nonnote_nondebug_insn (insn),
For I1 -> I2 -> B; I2 -> A;
LOG_LINK can make sure I1 and I2 are single_set, but not A and B.
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, December 09, 2014 5:29 AM
> To: Zhenqiang Chen
> Cc: Steven Bosscher; gcc-patches@gcc.gnu.org; Jakub Jelinek
> Subject: Re: [PATCH] Fix PR 61225
>
> On 12/04/14 01:
On 12/06/2014 12:56 AM, Jakub Jelinek wrote:
> So, any other md than rx and mn10300 that uses the non-standard order?
>
Not that I'm aware of.
r~
On 12/04/14 01:43, Zhenqiang Chen wrote:
> >
> > Part of PR rtl-optimization/61225
> > * combine.c (refer_same_reg_p): New function.
> > (combine_instructions): Handle I1 -> I2 -> I3; I2 -> insn.
> > (try_combine): Add one more parameter TO_COMBINED_INSN, which
On 12/05/14 17:16, Segher Boessenkool wrote:
On Fri, Dec 05, 2014 at 03:31:54PM -0700, Jeff Law wrote:
Combine does not consider combining 9 into 7 because there is no LOG_LINK
between them (the link for r88 is between 8 and 7 already).
OK, yea, that's a long standing design decision. We don't
On Fri, Dec 05, 2014 at 06:09:11PM -0600, Segher Boessenkool wrote:
> On Fri, Dec 05, 2014 at 03:36:01PM -0700, Jeff Law wrote:
> > Zhenqiang, can you look at what happens if you provide a pattern for
> > 6+7+8 (probably via a define_and_split)?
>
> I tried this out yesterday. There are a few op
On Sat, Dec 06, 2014 at 09:38:43AM +0100, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine" instead of "compare"?
> >
> > The above should read "... that
On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > That's already what it does though, did you mean the opposite? Or did you
> > mean to write "combine" instead of "compare"?
>
> The above should read "... that existing RTX *combine* pass be updated
> ...", thanks for pointing out!
On Fri, Dec 5, 2014 at 6:15 PM, Eric Botcazou wrote:
>> --quote--
>> If we want to use this pass for x86, then for 4.8 we should also fix the
>> discrepancy between the compare-elim canonical
>>
>> [(operate)
>>(set-cc)]
>>
>> and the combine canonical
>>
>> [(set-cc)
>>(operate)]
>>
>
On Fri, Dec 05, 2014 at 01:40:56PM -0700, Jeff Law wrote:
> My first thought would be to allow both and have combine swap the order
> in the vector if recog doesn't recognize the pattern. One could argue
> we could go through a full permutation of ordering in the vector, but
> that's probably a
On Thu, Dec 04, 2014 at 02:57:56PM -0600, Segher Boessenkool wrote:
> Adding a bridge pattern in the target would work; or you can enhance combine
> so it can break up this parallel correctly.
I also investigated that second option. The enhancement transforms
the combine result
M = XXX :: T =
On Fri, Dec 05, 2014 at 03:31:54PM -0700, Jeff Law wrote:
> >Combine does not consider combining 9 into 7 because there is no LOG_LINK
> >between them (the link for r88 is between 8 and 7 already).
> OK, yea, that's a long standing design decision. We don't feed a single
> def into multiple use s
On Fri, Dec 05, 2014 at 03:36:01PM -0700, Jeff Law wrote:
> >So combine tries to combine 6+7+8; the RTL it comes up with is a parallel
> >of the memory decrement (without cc clobber, but that is fine), and setting
> >r88 to the mem minus one. There is no such pattern in the target, and
> >combine
On 12/04/14 13:57, Segher Boessenkool wrote:
So combine tries to combine 6+7+8; the RTL it comes up with is a parallel
of the memory decrement (without cc clobber, but that is fine), and setting
r88 to the mem minus one. There is no such pattern in the target, and
combine cannot break the paral
On 12/04/14 13:49, Segher Boessenkool wrote:
On Thu, Dec 04, 2014 at 04:43:34PM +0800, Zhenqiang Chen wrote:
C code:
if (!--*p)
rtl code:
6: r91:SI=[r90:SI]
7: {r88:SI=r91:SI-0x1;clobber flags:CC;}
8: [r90:SI]=r88:SI
9: flags:CCZ=cmp(r88:SI,0)
expected output:
On 12/04/14 00:41, Uros Bizjak wrote:
Hello!
I also wonder if compare-elim ought to be helping here. Isn't that the
point here, to eliminate the comparison and instead get it for free as
part of the arithmetic? If so, is it the fact that we have memory
references that prevents compare-elim fr
> --quote--
> If we want to use this pass for x86, then for 4.8 we should also fix the
> discrepancy between the compare-elim canonical
>
> [(operate)
>(set-cc)]
>
> and the combine canonical
>
> [(set-cc)
>(operate)]
>
> (Because of the simplicity of the substitution in compare-eli
On Thu, Dec 04, 2014 at 02:49:56PM -0600, Segher Boessenkool wrote:
> On Thu, Dec 04, 2014 at 04:43:34PM +0800, Zhenqiang Chen wrote:
> > C code:
> >
> > if (!--*p)
> >
> > rtl code:
> >
> > 6: r91:SI=[r90:SI]
> > 7: {r88:SI=r91:SI-0x1;clobber flags:CC;}
> > 8: [r90:SI]=r88:SI
>
On Thu, Dec 04, 2014 at 04:43:34PM +0800, Zhenqiang Chen wrote:
> C code:
>
> if (!--*p)
>
> rtl code:
>
> 6: r91:SI=[r90:SI]
> 7: {r88:SI=r91:SI-0x1;clobber flags:CC;}
> 8: [r90:SI]=r88:SI
> 9: flags:CCZ=cmp(r88:SI,0)
>
> expected output:
>
> 8: {flags:CCZ=cmp([r90:SI]
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, December 02, 2014 6:11 AM
> To: Zhenqiang Chen
> Cc: Steven Bosscher; gcc-patches@gcc.gnu.org; Jakub Jelinek
> Subject: Re:
Hello!
>> I also wonder if compare-elim ought to be helping here. Isn't that the
>> point here, to eliminate the comparison and instead get it for free as
>> part of the arithmetic? If so, is it the fact that we have memory
>> references that prevents compare-elim from kicking in?
>
> Yes, compa
> I also wonder if compare-elim ought to be helping here. Isn't that the
> point here, to eliminate the comparison and instead get it for free as
> part of the arithmetic? If so, is it the fact that we have memory
> references that prevents compare-elim from kicking in?
Yes, compare-elim doesn't
On 08/04/14 02:24, Zhenqiang Chen wrote:
ChangeLog:
2014-05-22 Zhenqiang Chen
Part of PR rtl-optimization/61225
* config/i386/i386-protos.h (ix86_peephole2_rtx_equal_p): New
proto.
* config/i386/i386.c (ix86_peephole2_rtx_equal_p): New function.
* reg
On 17 July 2014 11:10, Jeff Law wrote:
> On 05/22/14 03:52, Zhenqiang Chen wrote:
>>
>> On 21 May 2014 20:43, Steven Bosscher wrote:
>>>
>>> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
Hi,
The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
test
On 05/22/14 03:52, Zhenqiang Chen wrote:
On 21 May 2014 20:43, Steven Bosscher wrote:
On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
Hi,
The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
test case tends to check a peephole2 optimization, which optimizes the
following
On 21 May 2014 20:43, Steven Bosscher wrote:
> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
>> Hi,
>>
>> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
>> test case tends to check a peephole2 optimization, which optimizes the
>> following sequence
>>
>> 2: bx:SI=
On 21 May 2014 20:43, Steven Bosscher wrote:
> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
>> Hi,
>>
>> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
>> test case tends to check a peephole2 optimization, which optimizes the
>> following sequence
>>
>> 2: bx:SI=
On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
> Hi,
>
> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
> test case tends to check a peephole2 optimization, which optimizes the
> following sequence
>
> 2: bx:SI=ax:SI
> 25: ax:SI=[bx:SI]
> 7: {ax:SI=ax:SI-0x1
41 matches
Mail list logo
