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 rat
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 h
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
> st
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 nop_con
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
> > >> ++
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
> >>
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
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 */
(si
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, bootstrappe
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 trunk
10 matches
Mail list logo