On Mon, Mar 13, 2017 at 09:53:11AM +, Kyrill Tkachov wrote:
> >combine doesn't try to combine all producer-consumer pairs, only
> >producer with first consumer, because it would not often help and
> >could easily take much more time. On the other hand I'd love to get
> >rid of the LOG_LINKS an
On 10/03/17 23:56, Segher Boessenkool wrote:
On Fri, Mar 10, 2017 at 10:30:33AM +, Kyrill Tkachov wrote:
I'm trying to improve the cases where the result of the arithmetic
operation is used in multiple places besides the comparison.
For example:
add w0, w0, w1
add
On Fri, Mar 10, 2017 at 10:30:33AM +, Kyrill Tkachov wrote:
> I'm trying to improve the cases where the result of the arithmetic
> operation is used in multiple places besides the comparison.
> For example:
> add w0, w0, w1
> add w1, w0, 2
> cmp w0, 0
>
> Co
On 10/03/17 10:38, Jakub Jelinek wrote:
On Fri, Mar 10, 2017 at 10:10:34AM +, Kyrill Tkachov wrote:
Hi all,
Some (many?) targets have instructions that perform an arithmetic operation and
set the condition flags based on the result.
For example, on aarch64, we have instructions like ADDS,
On Fri, Mar 10, 2017 at 10:10:34AM +, Kyrill Tkachov wrote:
> Hi all,
>
> Some (many?) targets have instructions that perform an arithmetic operation
> and set the condition flags based on the result.
> For example, on aarch64, we have instructions like ADDS, SUBS, ANDS etc.
> In the machine
On 10/03/17 10:23, Eric Botcazou wrote:
My understanding was that the order of the two in this pattern here doesn't
matter because there is an implicit PARALLEL around them, but I found that
the compare-elimination pass (compare-elim.c) assumes that the COMPARE set
must be in the second positio
> My understanding was that the order of the two in this pattern here doesn't
> matter because there is an implicit PARALLEL around them, but I found that
> the compare-elimination pass (compare-elim.c) assumes that the COMPARE set
> must be in the second position for it to do the transformations i
