Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Fri, 6 Dec 2019, Richard Biener wrote: Although that will increase the code size. In case, we could still have both a nop_convert and a strip_nop predicates. Just thinking: We should measure it, yes, I hope it won't be too bad ;) In theory making genmatch emitted code more like a graph

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Fri, 6 Dec 2019, Richard Biener wrote: > On Fri, 6 Dec 2019, Marc Glisse wrote: > > > On Fri, 6 Dec 2019, Richard Biener wrote: > > > > >>> nop_convert sees that 'a' comes from a conversion, and only returns d > > >>> (unlike 'convert?' which would try both a and d). > > > > Maybe I should

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Fri, 6 Dec 2019, Marc Glisse wrote: > On Fri, 6 Dec 2019, Richard Biener wrote: > > >>> nop_convert sees that 'a' comes from a conversion, and only returns d > >>> (unlike 'convert?' which would try both a and d). > > Maybe I should have formulated it as: nop_convert works kind of like a >

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Fri, 6 Dec 2019, Richard Biener wrote: nop_convert sees that 'a' comes from a conversion, and only returns d (unlike 'convert?' which would try both a and d). Maybe I should have formulated it as: nop_convert works kind of like a strip_nops. If use gets more and more we can make

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Fri, 6 Dec 2019, Richard Biener wrote: > On Thu, Dec 5, 2019 at 4:16 PM Richard Biener wrote: > > > > On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse > > wrote: > > >On Wed, 4 Dec 2019, Jakub Jelinek wrote: > > > > > >> --- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100 > > >>

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Thu, Dec 5, 2019 at 4:16 PM Richard Biener wrote: > > On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse > wrote: > >On Wed, 4 Dec 2019, Jakub Jelinek wrote: > > > >> --- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100 > >> +++ gcc/match.pd 2019-12-03 13:36:01.084435697 +0100 >

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse wrote: >On Wed, 4 Dec 2019, Jakub Jelinek wrote: > >> --- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100 >> +++ gcc/match.pd 2019-12-03 13:36:01.084435697 +0100 >> @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY >> /* A

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Wed, 4 Dec 2019, Jakub Jelinek wrote: --- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100 +++ gcc/match.pd2019-12-03 13:36:01.084435697 +0100 @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY /* A - (A +- B) -> -+ B */ /* A +- (B -+ A) -> +- B */

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

On Wed, 4 Dec 2019, Jakub Jelinek wrote: > Hi! > > The following optimizations also can't handle nop conversions between the > inner and outer addition/subtraction, and even -fwrapv doesn't help there, > only simplify-rtx.c is able to do something about those. > > Implemented thusly,

[PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

Hi! The following optimizations also can't handle nop conversions between the inner and outer addition/subtraction, and even -fwrapv doesn't help there, only simplify-rtx.c is able to do something about those. Implemented thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for