> Are we in agreement that I should revert the patch?
I think that you can leave it for now in order to have some feedback (see for
example PR rtl-optimization/82597) but ideally it should be rewritten so as to
reuse the existing infrastructure of the pass.
--
Eric Botcazou
l...@redhat.com>; GCC Patches <gcc-patches@gcc.gnu.org>; Segher
Boessenkool <seg...@kernel.crashing.org>; Kyrill Tkachov
<kyrylo.tkac...@foss.arm.com>; nd <n...@arm.com>
Subject: RE: [PATCH][compare-elim] Merge zero-comparisons with normal ops
On October 17, 2
l...@redhat.com>; GCC Patches <gcc-patches@gcc.gnu.org>;
>Michael Collison <michael.colli...@arm.com>; Segher Boessenkool
><seg...@kernel.crashing.org>; Kyrill Tkachov
><kyrylo.tkac...@foss.arm.com>; nd <n...@arm.com>
>Subject: Re: [PATCH][compare-elim] Mer
> I see you have objected and indicated the additional cost. Have you
> quantified how much more expensive the pass is?
No, but use-def chains are known to be slow because DF is slow, see e.g. the
comment located a few lines below the call to try_merge_compare:
/* ??? This is one point at
tca...@adacore.com>
Cc: Jeff Law <l...@redhat.com>; GCC Patches <gcc-patches@gcc.gnu.org>; Michael
Collison <michael.colli...@arm.com>; Segher Boessenkool
<seg...@kernel.crashing.org>; Kyrill Tkachov <kyrylo.tkac...@foss.arm.com>; nd
<n...@arm.com>
Subject: Re: [P
On Sat, Oct 14, 2017 at 10:39 AM, Eric Botcazou wrote:
>> This looks good. OK for the trunk.
>
> FWIW I disagree. The patch completely shuns the existing implementation of
> the pass, which is based on a forward scan within basic blocks to identify the
> various
> This looks good. OK for the trunk.
FWIW I disagree. The patch completely shuns the existing implementation of
the pass, which is based on a forward scan within basic blocks to identify the
various interesting instructions and record them, and uses full-blown def-use
and use-def chains
On 09/06/2017 09:56 AM, Michael Collison wrote:
> Patch updated with all relevant comments and suggestions.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf, and
> aarch64-none-linux-gnu and x86_64.
>
> Ok for trunk?
>
> 2017-08-05 Kyrylo Tkachov
>
Ping ^ 2. Updated patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00390.html
Ping. Updated patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00390.html
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
Sent: Saturday, September 2, 2017 12:07 AM
To: Kyrill Tkachov <kyrylo.tkac...@foss.arm.com>
Cc: Jeff Law <l...@redhat.com>; Michael Collison <michael.colli...@arm.com>;
gcc-patches@gcc.gnu.org; nd <n...@arm.com&g
Hi!
On Tue, Aug 29, 2017 at 09:39:06AM +0100, Kyrill Tkachov wrote:
> On 28/08/17 19:26, Jeff Law wrote:
> >On 08/10/2017 03:14 PM, Michael Collison wrote:
> >>One issue that we keep encountering on aarch64 is GCC not making good use
> >>of the flag-setting arithmetic instructions
> >>like ADDS,
On 08/29/2017 02:39 AM, Kyrill Tkachov wrote:
>>> This scares combine away as x0 is used in insn 33 as well as the
>>> comparison in insn 34.
>>> I think the compare-elim pass can help us here.
>> Is it the multiple use or the hard register that combine doesn't
>> appreciate. The latter would
Hi Jeff,
Some comments since I wrote this patch some time ago...
On 28/08/17 19:26, Jeff Law wrote:
On 08/10/2017 03:14 PM, Michael Collison wrote:
Hi all,
One issue that we keep encountering on aarch64 is GCC not making good use of
the flag-setting arithmetic instructions
like ADDS, SUBS,
On 08/10/2017 03:14 PM, Michael Collison wrote:
> Hi all,
>
> One issue that we keep encountering on aarch64 is GCC not making good use of
> the flag-setting arithmetic instructions
> like ADDS, SUBS, ANDS etc. that perform an arithmetic operation and compare
> the result against zero.
> They
Ping. Original patch here:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00766.html
Hi all,
One issue that we keep encountering on aarch64 is GCC not making good use of
the flag-setting arithmetic instructions
like ADDS, SUBS, ANDS etc. that perform an arithmetic operation and compare the
result against zero.
They are represented in a fairly standard way in the backend as
17 matches
Mail list logo