On Tue, 13 Jun 2017, Bin.Cheng wrote:
> On Tue, Jun 13, 2017 at 12:48 PM, Richard Biener wrote:
> > On Tue, 13 Jun 2017, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Tue, 13 Jun 2017, Richard Sandiford wrote:
> >> >> Richard Biener writes:
> >> >> > So I've come back to PR
On Tue, Jun 13, 2017 at 12:48 PM, Richard Biener wrote:
> On Tue, 13 Jun 2017, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 13 Jun 2017, Richard Sandiford wrote:
>> >> Richard Biener writes:
>> >> > So I've come back to PR66313 and found a solution to the tailrecursion
>> >>
On Tue, 13 Jun 2017, Bin.Cheng wrote:
> On Tue, Jun 13, 2017 at 12:23 PM, Richard Sandiford
> wrote:
> > Richard Biener writes:
> >> On Tue, 13 Jun 2017, Richard Sandiford wrote:
> >>> Richard Biener writes:
> >>> > So I've come back to PR66313 and found a solution to the tailrecursion
> >>> >
On Tue, 13 Jun 2017, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 13 Jun 2017, Richard Sandiford wrote:
> >> Richard Biener writes:
> >> > So I've come back to PR66313 and found a solution to the tailrecursion
> >> > missed optimization when fixing the factoring folding to use a
On Tue, Jun 13, 2017 at 12:23 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, 13 Jun 2017, Richard Sandiford wrote:
>>> Richard Biener writes:
>>> > So I've come back to PR66313 and found a solution to the tailrecursion
>>> > missed optimization when fixing the factoring folding
Richard Biener writes:
> On Tue, 13 Jun 2017, Richard Sandiford wrote:
>> Richard Biener writes:
>> > So I've come back to PR66313 and found a solution to the tailrecursion
>> > missed optimization when fixing the factoring folding to use an unsigned
>> > type when we're not sure of overflow.
>>
On Tue, 13 Jun 2017, Richard Sandiford wrote:
> Richard Biener writes:
> > So I've come back to PR66313 and found a solution to the tailrecursion
> > missed optimization when fixing the factoring folding to use an unsigned
> > type when we're not sure of overflow.
> >
> > The folding part is iden
Richard Biener writes:
> So I've come back to PR66313 and found a solution to the tailrecursion
> missed optimization when fixing the factoring folding to use an unsigned
> type when we're not sure of overflow.
>
> The folding part is identical to my last try from 2015, the tailrecursion
> part ma
So I've come back to PR66313 and found a solution to the tailrecursion
missed optimization when fixing the factoring folding to use an unsigned
type when we're not sure of overflow.
The folding part is identical to my last try from 2015, the tailrecursion
part makes us handle intermittent stmts t
On Thu, 29 Oct 2015, Richard Biener wrote:
> We still regress gcc.dg/tree-ssa/tailrecursion-6.c with it though.
> There we have
>
> int
> foo (int a)
> {
> if (a)
> return a * (2 * (foo (a - 1))) + a + 1;
> else
> return 0;
> }
>
> and tailrecursio
On Tue, 27 Oct 2015, Joseph Myers wrote:
> On Tue, 27 Oct 2015, Richard Biener wrote:
>
> > When factoring a*b + a*c to (b + c)*a we have to guard against the
> > case of a == 0 as after the factoring b + c might overflow in that
> > case. Fixed by doing the addition in an unsigned type if requi
On Tue, 27 Oct 2015, Richard Biener wrote:
> When factoring a*b + a*c to (b + c)*a we have to guard against the
> case of a == 0 as after the factoring b + c might overflow in that
> case. Fixed by doing the addition in an unsigned type if required.
The same applies to a == -1 (consider b and c
When factoring a*b + a*c to (b + c)*a we have to guard against the
case of a == 0 as after the factoring b + c might overflow in that
case. Fixed by doing the addition in an unsigned type if required.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2015-10-27 Richard Biener
13 matches
Mail list logo
