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
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
11 matches
Mail list logo