On 12/09/2016 01:10 AM, Richard Biener wrote:
Yea. Not sure how often something like that would happen in practice, but
using the equivalence to simplify rather than for propagation seems like the
way to go.
I keep thinking about doing some similar in DOM, but haven't gotten around to
seeing w
On Wed, 7 Dec 2016, Jeff Law wrote:
> On 12/06/2016 03:16 AM, Richard Biener wrote:
> > On Tue, 6 Dec 2016, Richard Biener wrote:
> >
> > > On Mon, 5 Dec 2016, Jeff Law wrote:
> > >
> > > > On 12/02/2016 01:33 AM, Richard Biener wrote:
> > > > > > The LHS on the assignment makes it easier to ide
On 12/06/2016 03:16 AM, Richard Biener wrote:
On Tue, 6 Dec 2016, Richard Biener wrote:
On Mon, 5 Dec 2016, Jeff Law wrote:
On 12/02/2016 01:33 AM, Richard Biener wrote:
The LHS on the assignment makes it easier to identify when a tail call is
possible. It's not needed for correctness. Not
On 12/06/2016 01:25 AM, Richard Biener wrote:
But if the function returns the value from the tail call, then going through
an LHS is the right thing to do. Using the magic "argX will be the return
value" seems clever, but actually hurts in practice.
So we do want the reverse transform (for the
On Tue, 6 Dec 2016, Richard Biener wrote:
> On Mon, 5 Dec 2016, Jeff Law wrote:
>
> > On 12/02/2016 01:33 AM, Richard Biener wrote:
> > > > The LHS on the assignment makes it easier to identify when a tail call
> > > > is
> > > > possible. It's not needed for correctness. Not having the LHS on
On Mon, 5 Dec 2016, Jeff Law wrote:
> On 12/02/2016 01:33 AM, Richard Biener wrote:
> > > The LHS on the assignment makes it easier to identify when a tail call is
> > > possible. It's not needed for correctness. Not having the LHS on the
> > > assignment just means we won't get an optimized tai
On 12/02/2016 01:33 AM, Richard Biener wrote:
The LHS on the assignment makes it easier to identify when a tail call is
possible. It's not needed for correctness. Not having the LHS on the
assignment just means we won't get an optimized tail call.
Under what circumstances would the LHS possibl
On Thu, 1 Dec 2016, Jeff Law wrote:
> On 12/01/2016 06:22 AM, Richard Biener wrote:
> > > Well after removing DECL_BY_REFERENCE, verify_gimple still fails but
> > > differently:
> > >
> > > tail-padding1.C:13:1: error: RESULT_DECL should be read only when
> > > DECL_BY_REFERENCE is set
> > > }
>
On 2 December 2016 at 03:57, Jeff Law wrote:
> On 12/01/2016 06:22 AM, Richard Biener wrote:
>>>
>>> Well after removing DECL_BY_REFERENCE, verify_gimple still fails but
>>> differently:
>>>
>>> tail-padding1.C:13:1: error: RESULT_DECL should be read only when
>>> DECL_BY_REFERENCE is set
>>> }
>
On 12/01/2016 06:22 AM, Richard Biener wrote:
Well after removing DECL_BY_REFERENCE, verify_gimple still fails but
differently:
tail-padding1.C:13:1: error: RESULT_DECL should be read only when
DECL_BY_REFERENCE is set
}
^
while verifying SSA_NAME nrvo_4 in statement
# .MEM_3 = VDEF <.MEM_1(D)
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 18:38, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 1 December 2016 at 18:26, Richard Biener wrote:
> >> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 1 December 20
On 1 December 2016 at 18:38, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 1 December 2016 at 18:26, Richard Biener wrote:
>> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 1 December 2016 at 17:40, Richard Biener wrote:
>> >> > On Thu, 1 Dec 2016
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 18:26, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 1 December 2016 at 17:40, Richard Biener wrote:
> >> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 25 November 2
On 1 December 2016 at 18:26, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 1 December 2016 at 17:40, Richard Biener wrote:
>> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 25 November 2016 at 21:17, Jeff Law wrote:
>> >> > On 11/25/2016 01:07 AM,
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 1 December 2016 at 17:40, Richard Biener wrote:
> > On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> >
> >> On 25 November 2016 at 21:17, Jeff Law wrote:
> >> > On 11/25/2016 01:07 AM, Richard Biener wrote:
> >> >
> >> >>> For the tail-call, is
On 1 December 2016 at 17:40, Richard Biener wrote:
> On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
>
>> On 25 November 2016 at 21:17, Jeff Law wrote:
>> > On 11/25/2016 01:07 AM, Richard Biener wrote:
>> >
>> >>> For the tail-call, issue should we artificially create a lhs and use that
>> >>> as
On Thu, 1 Dec 2016, Prathamesh Kulkarni wrote:
> On 25 November 2016 at 21:17, Jeff Law wrote:
> > On 11/25/2016 01:07 AM, Richard Biener wrote:
> >
> >>> For the tail-call, issue should we artificially create a lhs and use that
> >>> as return value (perhaps by a separate pass before tailcall) ?
On 25 November 2016 at 21:17, Jeff Law wrote:
> On 11/25/2016 01:07 AM, Richard Biener wrote:
>
>>> For the tail-call, issue should we artificially create a lhs and use that
>>> as return value (perhaps by a separate pass before tailcall) ?
>>>
>>> __builtin_memcpy (a1, a2, a3);
>>> return a1;
>>>
On 11/25/2016 01:07 AM, Richard Biener wrote:
For the tail-call, issue should we artificially create a lhs and use that
as return value (perhaps by a separate pass before tailcall) ?
__builtin_memcpy (a1, a2, a3);
return a1;
gets transformed to:
_1 = __builtin_memcpy (a1, a2, a3)
return _1;
S
On 25 November 2016 at 13:55, Richard Biener wrote:
> On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 25 November 2016 at 13:37, Richard Biener wrote:
>> > On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 24 November 2016 at 18:08, Richard Biener wrote:
>> >> > On Thu, 24 No
On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
> On 25 November 2016 at 13:37, Richard Biener wrote:
> > On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
> >
> >> On 24 November 2016 at 18:08, Richard Biener wrote:
> >> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 24 Novem
On 25 November 2016 at 13:37, Richard Biener wrote:
> On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 24 November 2016 at 18:08, Richard Biener wrote:
>> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 24 November 2016 at 17:48, Richard Biener wrote:
>> >> > On Thu, 24 No
On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
> On 24 November 2016 at 18:08, Richard Biener wrote:
> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >
> >> On 24 November 2016 at 17:48, Richard Biener wrote:
> >> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> On 24 Novem
On 24 November 2016 at 18:08, Richard Biener wrote:
> On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 24 November 2016 at 17:48, Richard Biener wrote:
>> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>> >
>> >> On 24 November 2016 at 14:07, Richard Biener wrote:
>> >> > On Thu, 24 No
On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> On 24 November 2016 at 17:48, Richard Biener wrote:
> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >
> >> On 24 November 2016 at 14:07, Richard Biener wrote:
> >> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >> >
> >> >> Hi,
> >> >>
On 24 November 2016 at 17:48, Richard Biener wrote:
> On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 24 November 2016 at 14:07, Richard Biener wrote:
>> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>> >
>> >> Hi,
>> >> Consider following test-case:
>> >>
>> >> void *f(void *a1, void
On Thu, 24 Nov 2016, Jakub Jelinek wrote:
> On Thu, Nov 24, 2016 at 01:18:37PM +0100, Richard Biener wrote:
> > > eg:
> > > void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
> > > {
> > > void *t1 = __builtin_memcpy (a1, a2, a3);
> > > return t1;
> > > }
> > >
> > > After patch, copyprop transform
On Thu, Nov 24, 2016 at 01:18:37PM +0100, Richard Biener wrote:
> > eg:
> > void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
> > {
> > void *t1 = __builtin_memcpy (a1, a2, a3);
> > return t1;
> > }
> >
> > After patch, copyprop transformed it into:
> > t1 = __builtin_memcpy (a1, a2, a3);
> > retur
On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> On 24 November 2016 at 14:07, Richard Biener wrote:
> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> >
> >> Hi,
> >> Consider following test-case:
> >>
> >> void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
> >> {
> >> __builtin_memcpy (a1, a2,
On 24 November 2016 at 14:07, Richard Biener wrote:
> On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
>
>> Hi,
>> Consider following test-case:
>>
>> void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
>> {
>> __builtin_memcpy (a1, a2, a3);
>> return a1;
>> }
>>
>> return a1 can be considered equiva
On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote:
> Hi,
> Consider following test-case:
>
> void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
> {
> __builtin_memcpy (a1, a2, a3);
> return a1;
> }
>
> return a1 can be considered equivalent to return value of memcpy,
> and the call could be emitted
Hi,
Consider following test-case:
void *f(void *a1, void *a2, __SIZE_TYPE__ a3)
{
__builtin_memcpy (a1, a2, a3);
return a1;
}
return a1 can be considered equivalent to return value of memcpy,
and the call could be emitted as a tail-call.
gcc doesn't emit the above call to memcpy as a tail-cal
32 matches
Mail list logo
